CVSS 3.1 base metricsRed raises the risk · green lowers it
Attack vector
LocalAV:L
Attack complexity
LowAC:L
Privileges required
HighPR:H
User interaction
NoneUI:N
Scope
UnchangedS:U
Confidentiality
NoneC:N
Integrity
NoneI:N
Availability
HighA:H
Updates that fix it
0 KBs
No KB listed
No KB update is listed in the collected MSRC record. Check the MSRC advisory for product releases and other remedies.
Affected products
Open Source Software
3 affected products
azl3 kernel 6.6.157.1-1 on Azure Linux 3.0
azl3 kernel 6.6.159.1-1 on Azure Linux 3.0
azl3 kernel 6.6.161.1-1 on Azure Linux 3.0
What changed
Detection template: Unknown: detection-template evidence is incomplete or retained → No Nuclei template listed
Detection template: No Nuclei template listed → Unknown: detection-template evidence is incomplete or retained
Affected products: azl3 kernel 6.6.157.1-1 on Azure Linux 3.0, azl3 kernel 6.6.159.1-1 on Azure Linux 3.0 → azl3 kernel 6.6.157.1-1 on Azure Linux 3.0, azl3 kernel 6.6.159.1-1 on Azure Linux 3.0, azl3 kernel 6.6.161.1-1 on Azure Linux 3.0
Detection template: Unknown: detection-template evidence is incomplete or retained → No Nuclei template listed
Detection template: No Nuclei template listed → Unknown: detection-template evidence is incomplete or retained
Affected products: azl3 kernel 6.6.157.1-1 on Azure Linux 3.0 → azl3 kernel 6.6.157.1-1 on Azure Linux 3.0, azl3 kernel 6.6.159.1-1 on Azure Linux 3.0
Detection template: No Nuclei template listed · Customer action: Required: apply the update → Required: follow the MSRC remediation guidance · Public disclosure: No → Unknown: not stated by MSRC · Exploitation detected: Not reported by MSRC → Unknown: not stated by MSRC
Detection template: Unknown: exploit-code evidence is incomplete or retained → No Nuclei template listed · CISA KEV: Unknown: catalog evidence is incomplete or retained → Not listed in the collected catalog
Detection template: No Nuclei template listed → Unknown: exploit-code evidence is incomplete or retained · CISA KEV: Not listed in the collected catalog → Unknown: catalog evidence is incomplete or retained
Page history
Changes are dated when recorded; day views use the last saved version from that UTC day, and citations stay fixed.
6 Nov 2026 · 09:07:49 UTCAffected productsazl3 kernel 6.6.157.1-1 on Azure Linux 3.0, azl3 kernel 6.6.159.1-1 on Azure Linux 3.0 → azl3 kernel 6.6.157.1-1 on Azure Linux 3.0, azl3 kernel 6.6.159.1-1 on Azure Linux 3.0, azl3 kernel 6.6.161.1-1 on Azure Linux 3.0
2 Nov 2026 · 17:30:39 UTCPublic detection templateUnknown: detection-template evidence is incomplete or retained → No Nuclei template listed
2 Nov 2026 · 09:04:36 UTCAffected productsazl3 kernel 6.6.157.1-1 on Azure Linux 3.0 → azl3 kernel 6.6.157.1-1 on Azure Linux 3.0, azl3 kernel 6.6.159.1-1 on Azure Linux 3.0
CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.
No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.
cve-program · CVE-2026-98789
Published
bpf: Fix objects stuck in free_by_rcu_ttrace
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.
This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.