CVE-2025-38115
BaseFortify
Publication date: 2025-07-03
Last updated on: 2025-12-17
Assigner: kernel.org
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux | linux_kernel | From 4.16 (inc) to 5.4.295 (exc) |
| linux | linux_kernel | From 5.5 (inc) to 5.10.239 (exc) |
| linux | linux_kernel | From 5.11 (inc) to 5.15.186 (exc) |
| linux | linux_kernel | From 5.16 (inc) to 6.1.142 (exc) |
| linux | linux_kernel | From 6.2 (inc) to 6.6.94 (exc) |
| linux | linux_kernel | From 6.7 (inc) to 6.12.34 (exc) |
| linux | linux_kernel | From 6.13 (inc) to 6.15.3 (exc) |
| linux | linux_kernel | 6.16 |
| debian | debian_linux | 11.0 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-401 | The product does not sufficiently track and release allocated memory after it has been used, making the memory unavailable for reallocation and reuse. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability is in the Linux kernel's net_sched component, specifically in the sch_sfq (Stochastic Fairness Queueing) module. The issue arises because SFQ assumes it can always queue at least one packet. However, due to a change, the queue length (q.len) can be incorrectly increased by packets in gso_skb (Generic Segmentation Offload socket buffers). This can cause an enqueue operation on an empty SFQ queue discipline (qdisc) to be immediately followed by a packet drop, potentially leading to a crash. The fix involves correcting the sfq_drop() function to properly clear the queue tail pointer in this scenario.
How can this vulnerability impact me? :
This vulnerability can cause a potential crash in the Linux kernel's network scheduling subsystem when handling certain network packets (gso_skb). Such a crash could lead to denial of service by disrupting network traffic processing, potentially affecting system stability and network performance.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by setting up a test environment that mimics the conditions triggering the issue. The provided commands create network namespaces, virtual Ethernet pairs, and configure the SFQ qdisc with specific parameters to reproduce the problematic behavior. The commands include: ip netns add lb; ip link add dev to-lb type veth peer name in-lb netns lb; ethtool -K to-lb tso off; ip netns exec lb ethtool -K in-lb gro on; ip link set dev to-lb up; ip -netns lb link set dev in-lb up; ip addr add dev to-lb 192.168.20.1/24; ip -netns lb addr add dev in-lb 192.168.20.2/24; tc qdisc replace dev to-lb root sfq limit 100; ip netns exec lb netserver; netperf -H 192.168.20.2 -l 100 & (repeated multiple times). These commands help simulate the conditions under which the SFQ qdisc may crash due to gso_skb handling.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation involves applying the fix that corrects the sfq_drop() function to properly clear q->tail when handling gso_skb packets, preventing the crash. Until a patched kernel version is deployed, you may consider disabling SFQ qdisc or avoiding configurations that trigger the issue, such as those involving gso_skb requeueing. Using the provided commands to test and verify the fix can also help ensure the vulnerability is addressed.