clsact: Fix use-after-free in init/destroy rollback asymmetry
Summary
| CVE | CVE-2026-23413 |
|---|---|
| State | PUBLISHED |
| Assigner | Linux |
| Source Priority | CVE Program / NVD first with legacy fallback |
| Published | 2026-04-02 12:16:20 UTC |
| Updated | 2026-04-03 16:10:52 UTC |
| Description | In the Linux kernel, the following vulnerability has been resolved: clsact: Fix use-after-free in init/destroy rollback asymmetry Fix a use-after-free in the clsact qdisc upon init/destroy rollback asymmetry. The latter is achieved by first fully initializing a clsact instance, and then in a second step having a replacement failure for the new clsact qdisc instance. clsact_init() initializes ingress first and then takes care of the egress part. This can fail midway, for example, via tcf_block_get_ext(). Upon failure, the kernel will trigger the clsact_destroy() callback. Commit 1cb6f0bae504 ("bpf: Fix too early release of tcx_entry") details the way how the transition is happening. If tcf_block_get_ext on the q->ingress_block ends up failing, we took the tcx_miniq_inc reference count on the ingress side, but not yet on the egress side. clsact_destroy() tests whether the {ingress,egress}_entry was non-NULL. However, even in midway failure on the replacement, both are in fact non-NULL with a valid egress_entry from the previous clsact instance. What we really need to test for is whether the qdisc instance-specific ingress or egress side previously got initialized. This adds a small helper for checking the miniq initialization called mini_qdisc_pair_inited, and utilizes that upon clsact_destroy() in order to fix the use-after-free scenario. Convert the ingress_destroy() side as well so both are consistent to each other. |
Risk And Classification
EPSS: 0.000180000 probability, percentile 0.046140000 (date 2026-04-07)
Vendor Declared Affected Products
| Source | Vendor | Product | Version | Platforms |
|---|---|---|---|---|
| CNA | Linux | Linux | affected 230bb13650b0f186f540500fd5f5f7096a822a2a a73d95b57bf9faebdfed591bcb7ed9292062a84c git | Not specified |
| CNA | Linux | Linux | affected 1cb6f0bae50441f4b4b32a28315853b279c7404e 37bef86e5428d59f70a4da82b80f9a8f252fecbe git | Not specified |
| CNA | Linux | Linux | affected 1cb6f0bae50441f4b4b32a28315853b279c7404e 4c9af67f99aa3e51b522c54968ab3ac8272be41c git | Not specified |
| CNA | Linux | Linux | affected 1cb6f0bae50441f4b4b32a28315853b279c7404e 0509b762bc5e8ea7b8391130730c6d8502fc6e69 git | Not specified |
| CNA | Linux | Linux | affected 1cb6f0bae50441f4b4b32a28315853b279c7404e a0671125d4f55e1e98d9bde8a0b671941987e208 git | Not specified |
| CNA | Linux | Linux | affected f61ecf1bd5b562ebfd7d430ccb31619857e80857 git | Not specified |
| CNA | Linux | Linux | affected 6.10 | Not specified |
| CNA | Linux | Linux | unaffected 6.10 semver | Not specified |
| CNA | Linux | Linux | unaffected 6.6.130 6.6.* semver | Not specified |
| CNA | Linux | Linux | unaffected 6.12.78 6.12.* semver | Not specified |
| CNA | Linux | Linux | unaffected 6.18.20 6.18.* semver | Not specified |
| CNA | Linux | Linux | unaffected 6.19.10 6.19.* semver | Not specified |
| CNA | Linux | Linux | unaffected 7.0-rc5 * original_commit_for_fix | Not specified |
References
| Reference | Source | Link | Tags |
|---|---|---|---|
| git.kernel.org/stable/c/4c9af67f99aa3e51b522c54968ab3ac8272be41c | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | git.kernel.org | |
| git.kernel.org/stable/c/0509b762bc5e8ea7b8391130730c6d8502fc6e69 | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | git.kernel.org | |
| git.kernel.org/stable/c/a0671125d4f55e1e98d9bde8a0b671941987e208 | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | git.kernel.org | |
| git.kernel.org/stable/c/37bef86e5428d59f70a4da82b80f9a8f252fecbe | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | git.kernel.org | |
| git.kernel.org/stable/c/a73d95b57bf9faebdfed591bcb7ed9292062a84c | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | git.kernel.org | |
| CVE Program record | CVE.ORG | www.cve.org | canonical |
| NVD vulnerability detail | NVD | nvd.nist.gov | canonical, analysis |
No vendor comments have been submitted for this CVE.
There are currently no legacy QID mappings associated with this CVE.