CVE-2025-38468 in Linux
Summary
by MITRE • 07/28/2025
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Return NULL when htb_lookup_leaf encounters an empty rbtree
htb_lookup_leaf has a BUG_ON that can trigger with the following:
tc qdisc del dev lo root tc qdisc add dev lo root handle 1: htb default 1 tc class add dev lo parent 1: classid 1:1 htb rate 64bit tc qdisc add dev lo parent 1:1 handle 2: netem tc qdisc add dev lo parent 2:1 handle 3: blackhole ping -I lo -c1 -W0.001 127.0.0.1
The root cause is the following:
1. htb_dequeue calls htb_dequeue_tree which calls the dequeue handler on the selected leaf qdisc 2. netem_dequeue calls enqueue on the child qdisc 3. blackhole_enqueue drops the packet and returns a value that is not just NET_XMIT_SUCCESS 4. Because of this, netem_dequeue calls qdisc_tree_reduce_backlog, and since qlen is now 0, it calls htb_qlen_notify -> htb_deactivate -> htb_deactiviate_prios -> htb_remove_class_from_row -> htb_safe_rb_erase 5. As this is the only class in the selected hprio rbtree, __rb_change_child in __rb_erase_augmented sets the rb_root pointer to NULL 6. Because blackhole_dequeue returns NULL, netem_dequeue returns NULL, which causes htb_dequeue_tree to call htb_lookup_leaf with the same hprio rbtree, and fail the BUG_ON
The function graph for this scenario is shown here: 0) | htb_enqueue() {
0) + 13.635 us | netem_enqueue(); 0) 4.719 us | htb_activate_prios(); 0) # 2249.199 us | } 0) | htb_dequeue() {
0) 2.355 us | htb_lookup_leaf(); 0) | netem_dequeue() {
0) + 11.061 us | blackhole_enqueue(); 0) | qdisc_tree_reduce_backlog() {
0) | qdisc_lookup_rcu() {
0) 1.873 us | qdisc_match_from_root(); 0) 6.292 us | } 0) 1.894 us | htb_search(); 0) | htb_qlen_notify() {
0) 2.655 us | htb_deactivate_prios(); 0) 6.933 us | } 0) + 25.227 us | } 0) 1.983 us | blackhole_dequeue(); 0) + 86.553 us | } 0) # 2932.761 us | qdisc_warn_nonwc(); 0) | htb_lookup_leaf() {
0) | BUG_ON(); ------------------------------------------
The full original bug report can be seen here [1].
We can fix this just by returning NULL instead of the BUG_ON, as htb_dequeue_tree returns NULL when htb_lookup_leaf returns NULL.
[1] https://lore.kernel.org/netdev/pF5XOOIim0IuEfhI-SOxTgRvNoDwuux7UHKnE_Y5-zVd4wmGvNk2ceHjKb8ORnzw0cGwfmVu42g9dL7XyJLf1NEzaztboTWcm0Ogxuojoeo=@willsroot.io/
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 01/25/2026
The vulnerability CVE-2025-38468 resides within the Linux kernel's traffic control subsystem, specifically in the Hierarchical Token Bucket (HTB) queuing discipline implementation. This flaw manifests as a kernel panic triggered by a BUG_ON condition when processing packet dequeuing operations through nested queuing disciplines. The issue occurs during the execution of complex queuing scenarios involving multiple nested qdiscs including netem and blackhole, which interact in a specific sequence leading to an empty red-black tree state that the current implementation does not properly handle.
The root cause stems from the interaction between several kernel subsystems and queuing disciplines. When a packet is processed through the HTB qdisc, the htb_dequeue_tree function calls htb_lookup_leaf to identify the appropriate leaf qdisc for packet processing. The problem arises when a netem qdisc is nested within an HTB structure, and a blackhole qdisc is used as a child of that netem qdisc. During packet processing, when the blackhole qdisc drops a packet and returns a non-success value, the netem qdisc's dequeue handler calls qdisc_tree_reduce_backlog which eventually leads to htb_remove_class_from_row and htb_safe_rb_erase operations. This process results in the removal of the last node from an hprio rbtree, leaving the tree root pointer set to NULL.
The technical flaw manifests as a failure in the htb_lookup_leaf function when it encounters an empty rbtree structure. The current implementation contains a BUG_ON assertion that expects the rbtree to contain nodes, but when the last node is removed and the tree becomes empty, this assertion fails and triggers a kernel panic. This represents a classic case of inadequate error handling in kernel space, where an edge case is not properly anticipated and handled, leading to system instability. The vulnerability is categorized under CWE-665 as improper initialization of a resource and CWE-476 as null pointer dereference, as the system fails to properly handle the case where a previously valid data structure becomes empty during normal operation.
The operational impact of this vulnerability is significant as it can cause a complete system crash when the specific sequence of queuing operations occurs. This affects any system running Linux kernel versions that include the vulnerable HTB implementation, particularly those using complex traffic control configurations with nested queuing disciplines. The vulnerability is exploitable through network traffic that triggers the specific queuing sequence, making it a potential denial-of-service vector that could be leveraged by malicious actors to destabilize systems. The attack surface includes any network service or application that utilizes the Linux kernel's traffic control mechanisms with nested qdisc configurations, which are common in network infrastructure, virtualized environments, and complex network routing scenarios.
The fix for this vulnerability involves modifying the htb_lookup_leaf function to return NULL instead of triggering a BUG_ON when encountering an empty rbtree. This change aligns with the established pattern in the kernel where functions that may fail gracefully return NULL to indicate failure, allowing the calling code to handle the error appropriately. The solution maintains the existing error handling flow by ensuring that htb_dequeue_tree properly handles the NULL return from htb_lookup_leaf, which is already expected behavior in the function's design. This approach follows the principle of graceful degradation and aligns with kernel development practices that favor returning error codes or NULL values rather than triggering kernel panics for recoverable conditions. The fix also aligns with ATT&CK technique T1499.004 for network denial of service, as it prevents the specific kernel panic condition that would otherwise lead to system instability. The mitigation strategy requires kernel updates that apply the patch to all affected systems, with no workaround possible since the issue lies in the fundamental handling of empty data structures within kernel space operations.