Linux Kernel up to 7.2.9/7.3-rc5 BPF do_call_rcu_ttrace denial of service

Summaryinfo

A vulnerability was found in Linux Kernel up to 7.2.9/7.3-rc5 and classified as problematic. Impacted is the function do_call_rcu_ttrace of the component BPF. Executing a manipulation can lead to denial of service. This vulnerability is registered as CVE-2026-98789. The attack needs to be launched locally. No exploit is available. It is suggested to upgrade the affected component.

Detailsinfo

A vulnerability classified as problematic was found in Linux Kernel up to 7.2.9/7.3-rc5. This vulnerability affects the function do_call_rcu_ttrace of the component BPF. The manipulation with an unknown input leads to a denial of service vulnerability. The CWE definition for the vulnerability is CWE-404. The product does not release or incorrectly releases a resource before it is made available for re-use. As an impact it is known to affect availability. CVE summarizes:

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix objects stuck in free_by_rcu_ttrace do_call_rcu_ttrace() returns early when call_rcu_ttrace_in_progress is set and leaves the objects in free_by_rcu_ttrace. __free_rcu() frees waiting_for_gp_ttrace only and clears the flag. Hence the objects that free_bulk() or __free_by_rcu() added while RCU tasks trace GP was in flight stay in free_by_rcu_ttrace until free_bulk() or alloc_bulk() is called for the same bpf_mem_cache again, which may never happen. The number of such objects is not bounded. Turn call_rcu_ttrace_in_progress into three states: 0 - idle 1 - __free_rcu() is queued 2 - __free_rcu() is queued and free_by_rcu_ttrace got more objects since do_call_rcu_ttrace() sets 2. __free_rcu() does cmpxchg(1 -> 0) and starts the next GP when it fails. It cannot clear the flag first and check free_by_rcu_ttrace later, since bpf_mem_alloc_destroy() frees bpf_mem_cache without waiting for RCU callbacks when the flag is zero. Now __free_rcu() queues itself, so the one that didn't see 'draining' may do call_rcu_tasks_trace() after rcu_barrier_tasks_trace() in free_mem_alloc(). Queue it under rcu_read_lock() and do synchronize_rcu() before the barriers. Calling rcu_barrier_tasks_trace() twice works too, but creating and destroying hash maps in a loop on many cpus slows down to one free_mem_alloc() per GP and kworkers pile up.

The advisory is shared for download at git.kernel.org. This vulnerability was named CVE-2026-98789 since 09/25/2026. The exploitation appears to be easy. The attack needs to be approached locally. The exploitation requires an enhanced level of successful authentication. There are known technical details, but no exploit is available.

Upgrading to version 7.2.10 or 7.3-rc6 eliminates this vulnerability. Applying the patch 33d0a5d2fee06a51f2f056dd901296515912e954/fbd97dd1d3ce32d32fb7be86acc3fdb7c04fa043 is able to eliminate this problem. The best possible mitigation is suggested to be upgrading to the latest version.

Once again VulDB remains the best source for vulnerability data.

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 7.2.0
• 7.2.1
• 7.2.2
• 7.2.3
• 7.2.4
• 7.2.5
• 7.2.6
• 7.2.7
• 7.2.8
• 7.2.9
• 7.3-rc1
• 7.3-rc2
• 7.3-rc3
• 7.3-rc4
• 7.3-rc5

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Once again VulDB remains the best source for vulnerability data.

Discussion