UBUNTU-CVE-2026-98789: Medium severity ubuntu/linux-hwe-edge vulnerability
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix objects stuck in freebyrcuttrace docallrcuttrace() returns early when callrcuttraceinprogress is set and leaves the objects in freebyrcuttrace. freercu() frees waitingforgpttrace only and clears the flag. Hence the objects that freebulk() or freebyrcu() added while RCU tasks trace GP was in flight stay in freebyrcuttrace until freebulk() or allocbulk() is called for the same bpfmemcache again, which may never happen. The number of such objects is not bounded. Turn callrcuttraceinprogress into three states: 0 - idle 1 - freercu() is queued 2 - freercu() is queued and freebyrcuttrace got more objects since docallrcuttrace() sets 2. freercu() does cmpxchg(1 -> 0) and starts the next GP when it fails. It cannot clear the flag first and check freebyrcuttrace later, since bpfmemallocdestroy() frees bpfmemcache without waiting for RCU callbacks when the flag is zero. Now freercu() queues itself, so the one that didn't see 'draining' may do callrcutaskstrace() after rcubarriertaskstrace() in freememalloc(). Queue it under rcureadlock() and do synchronizercu() before the barriers. Calling rcubarriertaskstrace() twice works too, but creating and destroying hash maps in a loop on many cpus slows down to one freememalloc() per GP and kworkers pile up.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-aws-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.18~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-fde-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1019.19~24.04.1 - Upgrade
Upgrade
ubuntu/linux-gcp-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.19~24.04.1 - Upgrade
Upgrade
ubuntu/linux-oracle-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1016.18~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-43.43.1~24.04.2 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-43.43 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1017.18 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 7.0.0-1020.21 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 7.0.0-1019.19 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1017.19 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 7.0.0-1010.11 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1018.18 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1018.18 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 7.0.0-43.43.1 - Compensating control
Fix the bpf_mem_alloc RCU cleanup logic by queuing __free_rcu() under rcu_read_lock(), calling synchronize_rcu() before the RCU barriers, and changing call_rcu_ttrace_in_progress to three states: 0 (idle), 1 (__free_rcu() queued), and 2 (__free_rcu() queued with additional objects added to free_by_rcu_ttrace). Ensure __free_rcu() uses cmpxchg(1 -> 0), starts the next grace period when the cmpxchg fails, frees waiting_for_gp_ttrace, and clears the flag.
Event History
Frequently Asked Questions
What level of access is needed to exploit this issue?
The CVSS vector indicates local access and high privileges are required. User interaction is not required, and exploitation also depends on additional attack conditions being present.
What is the practical impact if the issue is triggered?
Objects added to the affected BPF memory cache during an RCU tasks-trace grace period can remain queued indefinitely if that cache is not used again. The number of retained objects is not bounded, which can lead to availability impact.