{"id":"CVE-2026-98273","title":"In the Linux kernel, the following vulnerability has been resolved:\n\nx86/kprobes: Fix crash when probing CS CALL instructions\n\nWhen using eBPF to probe CS CALL instructions within a function,\na crash can be triggered.\n\nThe eBPF tool prob…","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nx86/kprobes: Fix crash when probing CS CALL instructions\n\nWhen using eBPF to probe CS CALL instructions within a function,\na crash can be triggered.\n\nThe eBPF tool prob…","severity":"none","vendor":"Linux","product":"Linux","affected":["Linux >= 6256e668b7af9d81472e03c6a171630c08f8858a < cfc1af3d054aaabee08f1f77c441b3533b082869","Linux >= 6256e668b7af9d81472e03c6a171630c08f8858a < d8c6a18c0552135cbf0c696c9019b2979d0862c9","Linux >= 6256e668b7af9d81472e03c6a171630c08f8858a < a5f7a5bb3b7f28ba7e4fa246775b29a0e5537255","Linux ba7d1dae9fe866abe74bb1e849fb85983b7c4c37","Linux >= 5.10.190 < 5.11","Linux 5.13"],"published":"2026-10-06","updated":"2026-10-06","sourceUpdated":"2026-10-06T09:18:16.937","source":"NVD","sourceUrl":"https://nvd.nist.gov/vuln/detail/CVE-2026-98273","references":[{"url":"https://git.kernel.org/stable/c/a5f7a5bb3b7f28ba7e4fa246775b29a0e5537255","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/cfc1af3d054aaabee08f1f77c441b3533b082869","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/d8c6a18c0552135cbf0c696c9019b2979d0862c9","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"}],"tags":["nvd","cve.org"],"ingestedAt":"2026-10-06T08:50:17.424Z","slug":"CVE-2026-98273","body":"## Overview\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/kprobes: Fix crash when probing CS CALL instructions\n\nWhen using eBPF to probe CS CALL instructions within a function,\na crash can be triggered.\n\nThe eBPF tool probes offset 257 of the __hrtimer_run_queues()\nfunction:\n\n<__hrtimer_run_queues+249>:  nopl   0x0(%rax,%rax,1)\n<__hrtimer_run_queues+254>:  mov    %r14,%rdi\n<__hrtimer_run_queues+257>:  cs call <__x86_indirect_thunk_r12>\n<__hrtimer_run_queues+263>:  mov    %eax,%r12d\n<__hrtimer_run_queues+266>:  xchg   %ax,%ax\n<__hrtimer_run_queues+268>:  mov    %r13,%rdi\n\nWhich triggers this crash:\n\n  BUG: unable to handle page fault for address: 00000000000f41c9\n  #PF: supervisor write access in kernel mode\n  #PF: error_code(0x0002) - not-present page\n  PGD 0 P4D 0\n  Oops: 0002 [#1] SMP NOPTI\n  CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: P\n  RIP: 0010:__hrtimer_run_queues+0x106/0x230\n\nNote that __hrtimer_run_queues+0x106 is __hrtimer_run_queues+262, which is\nat the 6th byte of the above CS CALL instruction. Since the CS CALL\ninstruction occupies 6 bytes, the exception occurred in the middle of that\ncall instruction.\n\nThe root cause is that when using eBPF tools to probe in the middle of a\nfunction, a kprobe with INT3 is used as the underlying implementation.\n\nDuring single-step emulation of the original CALL instruction,\nint3_emulate_call() assumes that the probed CALL instruction is 5 bytes\nlong. However, the actual CS-prefixed CALL instruction occupies 6 bytes,\nso it constructs an incorrect exception return address. When the CPU\nreturns from the kprobe handler, the next instruction to be executed is at\nthe address of the last byte of that CS CALL instruction. Coincidentally,\nstarting from that address, the CPU fetches and decodes a completely\ndifferent instruction, which ultimately triggers a kernel crash.\n\nFix the issue by using the actual instruction length obtained from\nthe instruction decoder when constructing the exception return\naddress, rather than relying on the hardcoded CALL_INSN_SIZE macro.\n\n[ mingo: Refined the changelog ]\n\n## Remediation\n\nRefer to the linked advisories for vendor-supplied fixes and affected version ranges.","depth":"sunlit","depthScore":3,"depthScoreParts":{"impact":2.8,"likelihood":0,"exploitation":0,"ransomware":0},"changes":[]}