CVE-2026-74620: net/sched: act_gact, act_police: range check the fallback control action
In the Linux kernel, the following vulnerability has been resolved:
net/sched: actgact, actpolice: range check the fallback control action
tcfactioncheckctrlact() range checks the primary control action:
if (!opcode) ret = action > TCACTVALUEMAX ? -EINVAL : 0;
TCACTVALUEMAX is TCACTTRAP, so kernel-internal verdicts above it cannot be set that way. But actgact and actpolice each carry a second, independent control action supplied by user space that never reaches that helper - TCAGACTPROB.paction and TCAPOLICERESULT. Both only reject TCACTGOTOCHAIN, so any other value is stored verbatim and returned verbatim from the action.
In particular user space can store TCACTCONSUMED, which is TCACTVALUEMAX + 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: schhandleingress(), schhandleegress() and tcfqeventhandle() all deliberately skip the free for it. The result is one leaked skbuff plus its data buffer per packet traversing the filter, unbounded, for all traffic on the chain including kernel-generated packets.
Both are trivially deterministic. actgact clamps tcfgpval to >= 1, so with pval = 1 gactdeterm() returns the fallback for every packet. actpolice has no mandatory rate, so rate = 0 leaves tcfpmtu = ~0 and tcfpolicemtucheck() always passes.
TCACTCONSUMED was added by commit 720f22fed81b ("net: sched: refactor reinsert action"), after both goto-chain guards were written: commit 9469f375ab09 ("net/sched: actgact: disallow 'goto chain' on fallback control action") and commit c08f5ed5d625 ("net/sched: actpolice: disallow 'goto chain' on fallback control action"). Neither guard was widened when the new verdict appeared.
Factor the existing range test out of tcfactioncheckctrlact() as tcfactionvalid() and apply it to both fallbacks. The helper cannot call tcfactioncheckctrlact() directly because that also allocates a gotochain, which is exactly what these two sites must not do.
Reproduced on v7.2-rc6: kmemleak reports one leaked 232-byte skbuffheadcache object plus its 704-byte data buffer per packet. With this patch both configurations are rejected with -EINVAL and kmemleak reports none.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.152.1-1
Event History
Frequently Asked Questions
Which traffic-control settings can trigger the leak?
The affected fallback controls are TCA_GACT_PROB.paction for act_gact and TCA_POLICE_RESULT for act_police. A fallback value of TC_ACT_CONSUMED causes the action to report ownership of the skb without any caller freeing it.
What is required to exploit this issue?
An attacker needs to be able to supply a fallback control action through the affected act_gact or act_police configuration. The vulnerable paths previously rejected only TC_ACT_GOTO_CHAIN, allowing TC_ACT_CONSUMED to be stored and returned.
What is the operational impact once the affected action is on a traffic path?
Each packet traversing the relevant filter leaks one sk_buff and its data buffer. The leak is deterministic and unbounded, and includes kernel-generated traffic on the affected chain.
What can be checked if patching is not immediately possible?
Inspect act_gact probabilistic fallback actions and act_police result actions for TC_ACT_CONSUMED or other values outside the UAPI control-action range. Avoid configurations that use TC_ACT_CONSUMED as a fallback action on traffic-processing chains.