{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-98530 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-98530 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-98530 and fix it if it is affected.\n\nWhat it is: CVE-2026-98530 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-98530 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-98530/ (Markdown: https://insights.sbomify.com/CVE-2026-98530/index.md)","id":"CVE-2026-98530","markdown":"https://insights.sbomify.com/CVE-2026-98530/index.md","name":"CVE-2026-98530","record":{"aliases":["DEBIAN-CVE-2026-98530","GHSA-2p4m-w3h2-4q6g","UBUNTU-CVE-2026-98530"],"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":"high_privilege","summary":"A local attacker with root privileges can cause a permanent system hang by disabling kprobes optimization while a probe is active.","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\nkprobes: Fix permanent hang when flushing the kprobe optimizer\n\nWriting 0 to /proc/sys/debug/kprobes-optimization while a kprobe is\njump-optimized never returns. The writer sleeps in D state forever with\nkprobe_sysctl_mutex held, so any later read or write of that sysctl\nhangs as well. For example, with vfs_read+9 as an optimizable address\nin this build:\n\n  # cd /sys/kernel/tracing\n  # echo 'p:myprobe vfs_read+9' \u003e\u003e kprobe_events\n  # echo 1 \u003e events/kprobes/myprobe/enable\n  # # wait until /sys/kernel/debug/kprobes/list shows [OPTIMIZED]\n  # echo 0 \u003e /proc/sys/debug/kprobes-optimization\n\n  INFO: task sh:246 blocked for more than 10 seconds.\n  Call Trace:\n   \u003cTASK\u003e\n   __schedule+0x1176/0x4f70\n   schedule+0xdc/0x2c0\n   schedule_timeout+0x17b/0x260\n   wait_for_completion+0x173/0x3c0\n   wait_for_kprobe_optimizer_locked+0xbc/0x130\n   proc_kprobes_optimization_handler+0x156/0x1b0\n   proc_sys_call_handler+0x324/0x490\n   vfs_write+0x52d/0xfe0\n   ksys_write+0xff/0x200\n   do_syscall_64+0x106/0x630\n   entry_SYSCALL_64_after_hwframe+0x77/0x7f\n   \u003c/TASK\u003e\n  ...\n  INFO: task cat:265 is blocked on a mutex likely owned by task sh:246.\n\nwait_for_kprobe_optimizer_locked() reinitializes optimizer_completion,\nasks the optimizer thread to flush and sleeps in wait_for_completion().\nThe thread drains the (un)optimizing lists, but calls complete() only\nif completion_done() is true, i.e. if the completion is already done,\nwhich never happens while someone waits. disarm_all_kprobes() and\nkprobe_trace_self_tests_init() wait the same way.\n\nCalling complete() unconditionally would not be enough: the waiter\ndrops kprobe_mutex while it sleeps, and nothing else serializes the\nsysctl handler against the debugfs \"enabled\" file. A second flusher\nthat still finds the lists non-empty, e.g. because a disabled probe is\nqueued for unoptimizing, reinitializes the completion under the first:\n\n  sysctl write                      debugfs \"enabled\" write\n  unoptimize_all_kprobes()\n    wait_for_kprobe_optimizer_locked()\n      init_completion(c)\n      mutex_unlock(\u0026kprobe_mutex)\n      wait_for_completion(c)\n                                    disarm_all_kprobes()\n                                      wait_for_kprobe_optimizer_locked()\n                                        init_completion(c)\n                                          // c-\u003ewait is reset, the first\n                                          // waiter is off the queue\n                                        mutex_unlock(\u0026kprobe_mutex)\n                                        wait_for_completion(c)\n  kprobe_optimizer()\n    complete(c)\n      // wakes the debugfs writer only\n\nwhere c is \u0026optimizer_completion. Lining up the two writes during an\noptimizer pass loses the sysctl writer this way.\n\nReplace the completion with a counter of optimizer passes, bumped at the\nend of each pass and signalled with wake_up_var_locked(), both under\nkprobe_mutex. A flusher samples the count and waits with\nwait_var_event_mutex(), which drops kprobe_mutex only while sleeping, so\na new count means a whole pass ran in the meantime. Nothing is\nreinitialized, so several flushers can sleep in the wait at once.","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":"kprobes: Fix permanent hang when flushing the kprobe optimizer","id":"CVE-2026-98530","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"denial_of_service","year":"2026"},"n_packages":0,"n_references":2,"next":{"headline":"ipv6: sr: enforce exact attribute length for SEG6_ATTR_DST","id":"CVE-2026-98531"},"packages":[],"prev":{"headline":"gpio: arizona: Fix runtime PM leak in arizona_gpio_direction_out()","id":"CVE-2026-98529"},"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 with root privileges can cause a permanent system hang by disabling kprobes optimization while a probe is active.","url":"https://insights.sbomify.com/CVE-2026-98530/"}