{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-98644 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-98644 is a denial of service vulnerability in Linux, published on 18 Oct 2026. It can only be exploited from the same machine or local network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2026-98644 and fix it if it is affected.\n\nWhat it is: CVE-2026-98644 is a denial of service vulnerability in Linux, published on 18 Oct 2026. It can only be exploited from the same machine or local network, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2026-98644 in the wild and no public exploit code.\n\nAffected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2026-98644/ (Markdown: https://insights.sbomify.com/CVE-2026-98644/index.md)","id":"CVE-2026-98644","markdown":"https://insights.sbomify.com/CVE-2026-98644/index.md","name":"CVE-2026-98644","record":{"aliases":["AZL-108839","BELL-CVE-2026-98644","DEBIAN-CVE-2026-98644","GHSA-p6rx-8wrq-4gc7","UBUNTU-CVE-2026-98644"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel","requires_auth":"low_privilege","summary":"A local attacker can trigger a soft lockup in the Linux kernel BPF subsystem by performing batch lookups on large hash maps, causing a denial of service.","user_interaction":"not_required","vuln_class":"denial_of_service"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Avoid soft lockup in __htab_map_lookup_and_delete_batch()\n\n__htab_map_lookup_and_delete_batch() has no rescheduling point. The\nbatch count bounds how many entries are copied out, not how many\nbuckets are visited, so one BPF_MAP_LOOKUP_BATCH call can walk the\nmap end to end. The empty-bucket fast path is worse: it stays inside\na single rcu_read_lock() / bpf_disable_instrumentation() section for\nany run of consecutive empty buckets.\n\nThat holds up on small maps, but it falls apart at scale. On a\n144-CPU arm64 host running a CONFIG_PREEMPT_NONE kernel, periodic\nBPF_MAP_LOOKUP_BATCH calls against an LRU hash map with 16,777,216\nbuckets held a CPU inside the batch op for 77+ seconds and triggered\nthe soft lockup watchdog.\n\nCommit 75134f16e7dd (\"bpf: Add schedule points in batch ops\") fixed this\nsame problem in the generic batch ops, but not in this htab-native path,\nwhich every htab-based hash map variant uses for its lookup[_and_delete]\nbatch ops.\n\nComplete that fix here. Leave the critical section after 64 consecutive\nempty buckets, call cond_resched_tasks_rcu_qs(), and resume at the saved\nbucket cursor. No locks are held at that point, and resuming from the\ncursor is already the function's behavior for non-empty buckets. Add the\nsame call to the per-bucket loop after copy_to_user(), where every lock\nhas been dropped. cond_resched_rcu() is not enough here: sleeping with\nbpf_prog_active elevated makes tracing programs on that CPU silently\nskip their invocations.\n\nPlain cond_resched() is not enough either. It is a no-op under PREEMPT\nand PREEMPT_LAZY, the only models arm64 and x86 have offered since\ncommit 7dadeaa6e851 (\"sched: Further restrict the preemption modes\").\nIt is also never a Tasks RCU quiescent state, in any model: the\nreschedule counts as a preemption. The walking task stays a holdout and\nstalls every synchronize_rcu_tasks() caller, ftrace and BPF trampoline\nteardown included, until the syscall returns [1].\ncond_resched_tasks_rcu_qs() is the usual tool for that [2]. It reports\nthe quiescent state at each yield and still reschedules as\ncond_resched() does on PREEMPT_NONE and PREEMPT_VOLUNTARY kernels.","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"bpf: Avoid soft lockup in __htab_map_lookup_and_delete_batch()","id":"CVE-2026-98644","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"denial_of_service","year":"2026"},"n_packages":0,"n_references":7,"next":{"headline":"HID: winwing: fix use-after-free in force feedback teardown","id":"CVE-2026-98645"},"packages":[],"prev":{"headline":"bpf: Fix out-of-bounds read of rtt_min in sock_ops","id":"CVE-2026-98643"},"products":["Linux"],"published":"2026-10-18","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-10-19","vendors":["Linux"]},"summary":"A local attacker can trigger a soft lockup in the Linux kernel BPF subsystem by performing batch lookups on large hash maps, causing a denial of service.","url":"https://insights.sbomify.com/CVE-2026-98644/"}