CVE-2024-41010: bpf: Fix too early release of tcx_entry
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix too early release of tcx_entry
Pedro Pinto and later independently also Hyunwoo Kim and Wongi Lee reported
an issue that the tcx_entry can be released too early leading to a use
after free (UAF) when an active old-style ingress or clsact qdisc with a
shared tc block is later replaced by another ingress or clsact instance.
Essentially, the sequence to trigger the UAF (one example) can be as follows:
1. A network namespace is created
2. An ingress qdisc is created. This allocates a tcx_entry, and
&tcx_entry->miniq is stored in the qdisc's miniqp->p_miniq. At the
same time, a tcf block with index 1 is created.
3. chain0 is attached to the tcf block. chain0 must be connected to
the block linked to the ingress qdisc to later reach the function
tcf_chain0_head_change_cb_del() which triggers the UAF.
4. Create and graft a clsact qdisc. This causes the ingress qdisc
created in step 1 to be removed, thus freeing the previously linked
tcx_entry:
rtnetlink_rcv_msg()
=> tc_modify_qdisc()
=> qdisc_create()
=> clsact_init() [a]
=> qdisc_graft()
=> qdisc_destroy()
=> __qdisc_destroy()
=> ingress_destroy() [b]
=> tcx_entry_free()
=> kfree_rcu() // tcx_entry freed
5. Finally, the network namespace is closed. This registers the
cleanup_net worker, and during the process of releasing the
remaining clsact qdisc, it accesses the tcx_entry that was
already freed in step 4, causing the UAF to occur:
cleanup_net()
=> ops_exit_list()
=> default_device_exit_batch()
=> unregister_netdevice_many()
=> unregister_netdevice_many_notify()
=> dev_shutdown()
=> qdisc_put()
=> clsact_destroy() [c]
=> tcf_block_put_ext()
=> tcf_chain0_head_change_cb_del()
=> tcf_chain_head_change_item()
=> clsact_chain_head_change()
=> mini_qdisc_pair_swap() // UAF
There are also other variants, the gist is to add an ingress (or clsact)
qdisc with a specific shared block, then to replace that qdisc, waiting
for the tcx_entry kfree_rcu() to be executed and subsequently accessing
the current active qdisc's miniq one way or another.
The correct fix is to turn the miniq_active boolean into a counter. What
can be observed, at step 2 above, the counter transitions from 0->1, at
step [a] from 1->2 (in order for the miniq object to remain active during
the replacement), then in [b] from 2->1 and finally [c] 1->0 with the
eventual release. The reference counter in general ranges from [0,2] and
it does not need to be atomic since all access to the counter is protected
by the rtnl mutex. With this in place, there is no longer a UAF happening
and the tcx_entry is freed at the correct time.
Security readout for executives and security teams
Plain-English summary
A Linux networking object can be freed while still in use, allowing a local low-privilege attacker meeting specific traffic-control conditions to corrupt kernel memory. Successful exploitation could compromise confidentiality, integrity, or availability. Exposure requires local access and deliberate manipulation of network namespaces and ingress or clsact queueing disciplines.
Executive priority
Prioritize remediation on multi-user or container-hosting Linux systems where less-trusted users control networking. The potential impact is full kernel compromise or outage, although exploitation requires local access and specialized traffic-control state. Validate exact exposure with distribution guidance because the supplied version boundaries are not unambiguous.
Technical view
A lifetime-management flaw releases tcx_entry while an active replacement qdisc can still reference its miniq, producing a use-after-free during cleanup or related paths. The fix replaces the miniq_active boolean with an RTNL-protected reference counter, preserving the object throughout qdisc replacement.
Likely exposure
Exposure is highest on affected Linux systems where untrusted local users can create network namespaces and manipulate relevant traffic-control objects. The bundle’s affected-version data is ambiguous, so administrators should verify their distribution kernel against vendor advisories and the listed stable fixes rather than relying only on version strings.
Exploitation context
The bundle marks this CVE as absent from KEV and provides no evidence of exploitation in the wild. It describes a local, low-privilege, low-complexity path requiring specifically arranged shared traffic-control blocks and qdisc replacement. KEV absence means exploitation is unconfirmed, not impossible.
Researcher notes
The vulnerable lifecycle involves ingress or clsact qdiscs using a shared tcf block. Replacing the qdisc can free tcx_entry before callbacks stop referencing miniq, causing a use-after-free during namespace cleanup or similar access. The reference-counter fix delays release until both users are gone. No CWE was supplied.
Mitigation direction
Install a vendor-supported kernel containing the tcx_entry lifetime fix.
Check distribution advisories because backported fixes may not match upstream version numbers.
Until patched, restrict untrusted users from managing network namespaces and traffic-control objects.
Prioritize shared, multi-user, and container-hosting systems with delegated networking capabilities.
Validation and detection
Inventory running kernel versions across Linux hosts and container platforms.
Confirm vendor changelogs or source patches include one of the listed stable fixes.
Review whether untrusted local users can create namespaces and alter qdiscs.
After updating, verify systems booted into the corrected kernel.
Review kernel crash records for use-after-free reports involving tcx_entry or mini_qdisc_pair_swap.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-41010 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.