fkie_cve-2025-39677
Vulnerability from fkie_nvd
Published
2025-09-05 18:15
Modified
2025-09-08 16:25
Severity ?
Summary
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.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/52bf272636bda69587952b35ae97690b8dc89941
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/a225f44d84b8900d679c5f5a9ea46fe9c0cc7802
Impacted products
Vendor Product Version


To clipboard 

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: Fix backlog accounting in qdisc_dequeue_internal\n\nThis issue applies for the following qdiscs: hhf, fq, fq_codel, and\nfq_pie, and occurs in their change handlers when adjusting to the new\nlimit. The problem is the following in the values passed to the\nsubsequent qdisc_tree_reduce_backlog call given a tbf parent:\n\n   When the tbf parent runs out of tokens, skbs of these qdiscs will\n   be placed in gso_skb. Their peek handlers are qdisc_peek_dequeued,\n   which accounts for both qlen and backlog. However, in the case of\n   qdisc_dequeue_internal, ONLY qlen is accounted for when pulling\n   from gso_skb. This means that these qdiscs are missing a\n   qdisc_qstats_backlog_dec when dropping packets to satisfy the\n   new limit in their change handlers.\n\n   One can observe this issue with the following (with tc patched to\n   support a limit of 0):\n\n   export TARGET=fq\n   tc qdisc del dev lo root\n   tc qdisc add dev lo root handle 1: tbf rate 8bit burst 100b latency 1ms\n   tc qdisc replace dev lo handle 3: parent 1:1 $TARGET limit 1000\n   echo \u0027\u0027; echo \u0027add child\u0027; tc -s -d qdisc show dev lo\n   ping -I lo -f -c2 -s32 -W0.001 127.0.0.1 2\u003e\u00261 \u003e/dev/null\n   echo \u0027\u0027; echo \u0027after ping\u0027; tc -s -d qdisc show dev lo\n   tc qdisc change dev lo handle 3: parent 1:1 $TARGET limit 0\n   echo \u0027\u0027; echo \u0027after limit drop\u0027; tc -s -d qdisc show dev lo\n   tc qdisc replace dev lo handle 2: parent 1:1 sfq\n   echo \u0027\u0027; echo \u0027post graft\u0027; tc -s -d qdisc show dev lo\n\n   The second to last show command shows 0 packets but a positive\n   number (74) of backlog bytes. The problem becomes clearer in the\n   last show command, where qdisc_purge_queue triggers\n   qdisc_tree_reduce_backlog with the positive backlog and causes an\n   underflow in the tbf parent\u0027s backlog (4096 Mb instead of 0).\n\nTo fix this issue, the codepath for all clients of qdisc_dequeue_internal\nhas been simplified: codel, pie, hhf, fq, fq_pie, and fq_codel.\nqdisc_dequeue_internal handles the backlog adjustments for all cases that\ndo not directly use the dequeue handler.\n\nThe old fq_codel_change limit adjustment loop accumulated the arguments to\nthe subsequent qdisc_tree_reduce_backlog call through the cstats field.\nHowever, this is confusing and error prone as fq_codel_dequeue could also\npotentially mutate this field (which qdisc_dequeue_internal calls in the\nnon gso_skb case), so we have unified the code here with other qdiscs."
    }
  ],
  "id": "CVE-2025-39677",
  "lastModified": "2025-09-08T16:25:38.810",
  "metrics": {},
  "published": "2025-09-05T18:15:44.043",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/52bf272636bda69587952b35ae97690b8dc89941"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/a225f44d84b8900d679c5f5a9ea46fe9c0cc7802"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.