{"id":"CVE-2026-98789","kind":"vulnerability","aliases":["CVE-2026-98789"],"related":[],"title":"Linux kernel BPF memory allocator can leak objects indefinitely","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix objects stuck in free_by_rcu_ttrace\n\ndo_call_rcu_ttrace() returns early when call_rcu_ttrace_in_progress is set\nand leaves the objects in free_by_rcu_ttrace. __free_rcu() frees\nwaiting_for_gp_ttrace only and clears the flag. Hence the objects that\nfree_bulk() or __free_by_rcu() added while RCU tasks trace GP was in flight\nstay in free_by_rcu_ttrace until free_bulk() or alloc_bulk() is called for\nthe same bpf_mem_cache again, which may never happen. The number of such\nobjects is not bounded.\n\nTurn call_rcu_ttrace_in_progress into three states:\n0 - idle\n1 - __free_rcu() is queued\n2 - __free_rcu() is queued and free_by_rcu_ttrace got more objects since\n\ndo_call_rcu_ttrace() sets 2. __free_rcu() does cmpxchg(1 -> 0) and starts\nthe next GP when it fails. It cannot clear the flag first and check\nfree_by_rcu_ttrace later, since bpf_mem_alloc_destroy() frees bpf_mem_cache\nwithout waiting for RCU callbacks when the flag is zero.\n\nNow __free_rcu() queues itself, so the one that didn't see 'draining' may\ndo call_rcu_tasks_trace() after rcu_barrier_tasks_trace() in\nfree_mem_alloc(). Queue it under rcu_read_lock() and do synchronize_rcu()\nbefore the barriers. Calling rcu_barrier_tasks_trace() twice works too, but\ncreating and destroying hash maps in a loop on many cpus slows down to one\nfree_mem_alloc() per GP and kworkers pile up.","summary":"The BPF memory allocator can leave freed objects stuck in a pending list when an RCU tasks trace grace period is in flight, because the free path returns early and never drains them. The sources describe a resource leak with unbounded growth, not a code execution or data disclosure path.","severity":"unknown","cvss":null,"epss":null,"exploited":false,"exploited_at":null,"products":[],"ecosystems":[],"tags":["bpf","kernel","linux","runtime","self-hosted"],"not_affected_if":["no-bpf-programs"],"how_to_check":"- Run `uname -r` and compare against the fixed kernel stable release listed in the NVD entry for CVE-2026-98789\n- Check whether BPF hash maps are created and destroyed in a loop on the host, which is the pattern the description says triggers the growth","fix":"- Update the Linux kernel to a stable release that includes the upstream commit 'bpf: Fix objects stuck in free_by_rcu_ttrace' (fixed version unknown from the sources)\n- Reboot into the patched kernel after the distribution ships it","status":"open","published_at":"2026-10-18T16:17:32+00:00","first_seen_at":"2026-10-23T21:57:16+00:00","triaged_at":"2026-10-25T05:15:17+00:00","updated_at":"2026-10-25T05:15:17+00:00","category":"runtime","confidence":0.5,"triage":{"at":"2026-10-25T05:15:17Z","model":"claude-haiku-5-5","output":{"fix":"- Update the Linux kernel to a stable release that includes the upstream commit 'bpf: Fix objects stuck in free_by_rcu_ttrace' (fixed version unknown from the sources)\n- Reboot into the patched kernel after the distribution ships it","reach":"local","title":"Linux kernel BPF memory allocator can leak objects indefinitely","impact":"low","summary":"The BPF memory allocator can leave freed objects stuck in a pending list when an RCU tasks trace grace period is in flight, because the free path returns early and never drains them. The sources describe a resource leak with unbounded growth, not a code execution or data disclosure path.","category":"runtime","nicknames":[],"who_cares":["linux","kernel","bpf","self-hosted"],"confidence":0.5,"needs_auth":"unknown","worst_case":"Kernel memory grows without bound, eventually degrading or exhausting the host","analyst_note":"Find the affected and fixed kernel version ranges and the upstream commit from the NVD entry or the kernel stable mailing list; the sources here give no versions.","how_to_check":"- Run `uname -r` and compare against the fixed kernel stable release listed in the NVD entry for CVE-2026-98789\n- Check whether BPF hash maps are created and destroyed in a loop on the host, which is the pattern the description says triggers the growth","needs_analyst":true,"not_affected_if":["no-bpf-programs"],"who_is_affected":"Systems running a Linux kernel with the BPF memory allocator that create and destroy BPF maps repeatedly, such as tracing or networking tooling on busy multi-CPU hosts. Hosts that do not load BPF programs or maps dynamically can likely skip it, but the sources do not say which kernel versions are affected.","user_interaction":"no","needs_special_setup":"unknown","severity_if_unknown":"unknown"},"cost_usd":0.00071,"input_tokens":3843,"output_tokens":652,"severity_before":"unknown"},"analyst_status":null,"analyst_note":null,"search":"'-2026':11A,14A '-98789':12A,15A '0':188C,220C '1':190C,219C '2':195C,214C 'add':137C 'alloc':5A,26B,156C,245C,288C,328C 'barrier':282C,301C,304C 'bound':178C 'bpf':3A,16B,24B,83C,163C,243C,248C 'bulk':132C,154C,157C 'cach':165C,250C 'call':93C,99C,159C,180C,210C,276C,302C 'callback':255C 'cannot':230C 'check':236C 'clear':124C,231C 'cmpxchg':218C 'code':67B 'cpus':321C 'creat':311C 'cve':10A,13A 'data':70B 'describ':58B 'destroy':246C,313C 'didn':270C 'disclosur':71B 'drain':54B,273C 'earli':51B,97C 'execut':68B 'fail':228C 'first':234C 'fix':84C 'flag':126C,233C,258C 'flight':45B,145C 'follow':78C 'free':48B,88C,111C,115C,117C,131C,134C,148C,153C,191C,196C,201C,215C,237C,247C,262C,286C,326C 'freed':29B 'got':205C 'gp':120C,142C,225C,330C 'grace':41B 'growth':64B 'happen':170C 'hash':314C 'henc':127C 'host':22B 'idl':189C 'indefinit':9A 'kernel':2A,17B,76C 'kworker':332C 'later':241C 'leak':7A,61B 'leav':28B,107C 'linux':1A,18B,75C 'list':35B 'lock':294C 'loop':318C 'mani':320C 'map':315C 'may':168C,274C 'mem':164C,244C,249C,287C,327C 'memori':4A,25B 'never':53B,169C 'next':224C 'number':172C 'object':8A,30B,85C,109C,129C,175C,207C 'one':268C,325C 'path':49B,72B 'pend':34B 'per':329C 'period':42B 'pile':333C 'progress':103C,184C 'queu':194C,199C 'queue':264C,289C 'rcu':38B,90C,94C,100C,113C,116C,136C,139C,150C,181C,192C,197C,203C,211C,216C,239C,254C,263C,277C,281C,292C,298C,303C 'read':293C 'resolv':82C 'resourc':60B 'return':50B,96C 'runtim':19B 'see':272C 'self':21B 'self-host':20B 'set':105C,213C 'sinc':208C,242C 'slow':322C 'sourc':57B 'start':222C 'state':187C 'stay':146C 'stuck':31B,86C 'synchron':297C 'task':39B,140C,278C,283C,305C 'three':186C 'trace':40B,141C,279C,284C,306C 'ttrace':91C,95C,101C,114C,121C,151C,182C,204C,212C,240C 'turn':179C 'twice':307C 'unbound':63B 'vulner':79C 'wait':118C,252C 'without':251C 'work':308C 'zero':260C","nicknames":[],"mitigations":[],"who_affected":"Systems running a Linux kernel with the BPF memory allocator that create and destroy BPF maps repeatedly, such as tracing or networking tooling on busy multi-CPU hosts. Hosts that do not load BPF programs or maps dynamically can likely skip it, but the sources do not say which kernel versions are affected.","tier":"C","verified":{},"analyst_revisit_at":null,"first_public_at":"2026-10-18T16:17:32+00:00","kev":null,"cvss_vector":null,"cvss_by":null,"poc_count":0,"sources":[{"source":"nvd","external_id":"CVE-2026-98789","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98789","severity":null,"published_at":"2026-10-18T16:17:32+00:00","modified_at":"2026-10-19T10:19:42+00:00","first_seen_at":"2026-10-23T21:57:16+00:00","fetched_at":"2026-10-23T22:28:56+00:00","note":null}],"documents":[],"notice":"Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai"}