Linux Kernel HFSC Reentrancy Vulnerability Leading to Use-After-Free

Vulnerability

A vulnerability in the Linux kernel's Hierarchical Fair Service Curve (HFSC) scheduling class can lead to a use-after-free (UAF) condition. This issue arises when HFSC is used with the Network Emulation (NETEM) queuing discipline. A recent patch intended to prevent reentrant enqueue operations by checking the class's active insertion count. However, this check can be bypassed, allowing the same class to be added twice to the scheduling tree. Under normal circumstances, this duplication would cause an infinite loop during packet dequeueing. However, by configuring a Token Bucket Filter (TBF) with a very low rate as the root queuing discipline, it is possible to exploit this behavior, causing further insertions into the HFSC scheduling tree and triggering the UAF condition.

Impact

Exploitation of this vulnerability causes a use-after-free condition, which can lead to memory corruption and potentially allow for arbitrary code execution.

Reproduction

To reproduce this vulnerability, first, set up a Linux environment with a version of the kernel that includes the vulnerable HFSC patch. Then, configure the HFSC scheduling class to use the HFSC_RSC flag, which allows for reentrant enqueue operations. Next, add NETEM as a child queuing discipline under HFSC. Finally, apply a TBF as the root queuing discipline, set with a very low rate to prevent packets from being dequeued. This combination of settings will trigger the vulnerability by causing the same class to be inserted twice into the HFSC scheduling tree, leading to the use-after-free condition.

Remediation

The vulnerability can be addressed by modifying the HFSC enqueue function to explicitly check whether a class is already in the scheduling tree before allowing a new insertion, especially when the HFSC_RSC flag is active.

Added: Jun 6, 2025, 3:31 PM
Updated: Jun 6, 2025, 3:31 PM

Vulnerability Rating

Custom Algorithm
spread
9.0
impact
2.5
exploitability
5.7
remediation
0.0
relevance
0.2
threat
4.8
urgency
2.9
incentive
1.7

Our algorithm analyzes dozens of metrics to generate these 8 key vulnerability categories, which are then combined to calculate the overall risk score.