GHSA-QGX8-C46G-4VMQ

Vulnerability from github – Published: 2026-10-06 09:31 – Updated: 2026-10-06 09:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

net/sched: hhf: cap hh_flows_limit at change time

hhf_change() stores TCA_HHF_HH_FLOWS_LIMIT with no upper bound. A huge hh_flows_limit lets each new heavy-hitter flow pass the hh_flows_current_cnt check in alloc_new_hh() and forces a fixed-size kzalloc(GFP_ATOMIC) per flow under spoofed traffic, for unbounded memory growth.

Bound the attribute with NLA_POLICY_MAX() at 2*HH_FLOWS_CNT (the hhf_init() default) and report the rejected value via extack. The deprecated nested parse is kept: legacy tc does not set NLA_F_NESTED on TCA_OPTIONS. Configs relying on hh_limit above the default were relying on unbounded, unsafe behaviour and are not supported going forward.

hhf_init() also ran hhf_change() before setting the default hh_flows_limit, so a user-supplied hh_limit at add time was clobbered back to 2048. Set the default before hhf_change() so the configured value sticks.

This is a follow-up to commit eb56a495f59b ("net/sched: hhf: clamp quantum in change and init paths"), which bounded the quantum of the same qdisc; the hh_flows_limit bound is the remaining unbounded knob of that series' scope.

Conditions to recreate the bug: CAP_NET_ADMIN in a user namespace; tc qdisc change dev X root hhf hh_limit 4294967295 succeeds and the value is echoed by tc qdisc show, unbounding heavy-hitter flow allocations; also tc qdisc add dev X root hhf hh_limit 500 stores 2048 instead of 500.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-98234"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-06T09:18:11Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: hhf: cap hh_flows_limit at change time\n\nhhf_change() stores TCA_HHF_HH_FLOWS_LIMIT with no upper bound. A huge\nhh_flows_limit lets each new heavy-hitter flow pass the\nhh_flows_current_cnt check in alloc_new_hh() and forces a fixed-size\nkzalloc(GFP_ATOMIC) per flow under spoofed traffic, for unbounded memory\ngrowth.\n\nBound the attribute with NLA_POLICY_MAX() at 2*HH_FLOWS_CNT (the\nhhf_init() default) and report the rejected value via extack. The\ndeprecated nested parse is kept: legacy tc does not set NLA_F_NESTED on\nTCA_OPTIONS. Configs relying on hh_limit above the default were relying\non unbounded, unsafe behaviour and are not supported going forward.\n\nhhf_init() also ran hhf_change() before setting the default\nhh_flows_limit, so a user-supplied hh_limit at add time was clobbered\nback to 2048. Set the default before hhf_change() so the configured\nvalue sticks.\n\nThis is a follow-up to commit eb56a495f59b (\"net/sched: hhf: clamp\nquantum in change and init paths\"), which bounded the quantum of the\nsame qdisc; the hh_flows_limit bound is the remaining unbounded knob of\nthat series\u0027 scope.\n\nConditions to recreate the bug: CAP_NET_ADMIN in a user namespace;\ntc qdisc change dev X root hhf hh_limit 4294967295 succeeds and the\nvalue is echoed by tc qdisc show, unbounding heavy-hitter flow\nallocations; also tc qdisc add dev X root hhf hh_limit 500 stores 2048\ninstead of 500.",
  "id": "GHSA-qgx8-c46g-4vmq",
  "modified": "2026-10-06T09:31:31Z",
  "published": "2026-10-06T09:31:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98234"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/06d2a101e89063cb0b9b459104db48bdfb0a797d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1731ff1d20489afe4cd01b7d16d37f324746ac54"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2cef2588c995722a901368def30befeef9ae55c6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/35fd423a5c5132c6f4321f6c4f0a7b4b90af830c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7adfd0a42174b85c6bd678858ecd6674f403f336"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d8e2f1f0263b7c97b222c06070cccf13e0ab7112"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f3f4a5cb4a6e9b1f1f25d34dfc25f836a1601db4"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f6547d27ce2093c5627636fb63dd0b7523c466f9"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.