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-02 12:16:20 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. |
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.