Look up another CVE · open CVE-2026-64235 in the interactive tracker
CVE-2026-64235
x86/ftrace: Relocate %rip-relative percpu refs in dynamic trampolines
Published 2026-07-24 (3 months ago) by the Linux kernel CNA. Subsystem arch/x86. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-64235 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | fixed | 6.12.94-1 | Update the kernel and reboot. Fixed in 6.12.94-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
With CONFIG_CALL_DEPTH_TRACKING enabled on an x86 retbleed-affected platform (eg: Skylake), with retbleed=stuff, registering a dynamic ftrace trampoline crashes on the first call into the traced function: BUG: unable to handle page fault for address: ffff88817ae18880 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 4b53067 P4D 4b53067 PUD 0 Oops: Oops: 0002 [#1] SMP PTI CPU: 3 UID: 0 PID: 187 Comm: usleep Not tainted 7.0.10 #243 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 Code: 24 78 00 00 00 00 48 89 ea 48 89 54 24 20 48 8b b4 24 b8 00 00 00 48 8b bc 24 b0 00 00 00 48 89 bc 24 80 00 00 00 48 83 ef 05 <65> 48 c1 3d 1f a8 b6 02 05 48 8b 15 f6 00 00 00 4c 89 3c 24 4c 89 Call Trace: <TASK> ? find_held_lock ? exc_page_fault ? lock_release ? __x64_sys_clock_nanosleep ? lockdep_hardirqs_on_prepare ? trace_hardirqs_on __x64_sys_clock_nanosleep do_syscall_64 ? exc_page_fault ? call_depth_return_thunk entry_SYSCALL_64_after_hwframe ... Kernel panic - not syncing: Fatal exception This small reproducer allows to easily trigger the crash: # echo 'p __x64_sys_clock_nanosleep' > /sys/kernel/tracing/kprobe_events # echo 1 > /sys/kernel/tracing/events/kprobes/p___x64_sys_clock_nanosleep_0/enable # usleep 1 Monitoring the crash under GDB points to the exact instruction in charge of incrementing the call depth: sarq $5, %gs:__x86_call_depth(%rip) This instruction matches the one inserted by the ftrace_regs_caller from ftrace_64.S. This emitted code was likely working fine until the introduction of 59bec00ace28 ("x86/percpu: Introduce %rip-relative addressing to PER_CPU_VAR()"): it has made the call depth accounting addressing relative to $rip, instead of being based on an absolute address. As this code exact location depends on where the trampoline lives in memory, the corresponding displacement needs to be adjusted at runtime to actually correctly find the per-cpu __x86_call_depth value, otherwise the targeted address is wrong, leading to the page fault seen above. Fix the %rip-relative displacement of the copied CALL_DEPTH_ACCOUNT instruction (from ftrace_regs_caller) by calling text_poke_apply_relocation(), as it is done for example by the x86 BPF JIT compiler through x86_call_depth_emit_accounting(). This corrects both CALL_DEPTH_ACCOUNT slots, in ftrace_caller and ftrace_regs_caller. [ bp: Massage. ]
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
arch/x86/kernel/ftrace.c
- What this is
- FUNCTION HOOKS (FTRACE)MAINTAINERS section matched on arch/*/*/*ftrace* · linux-kernel@vger.kernel.org · Maintained
Check it on the machine
grep -wE 'CONFIG_DYNAMIC_FTRACE|CONFIG_FTRACE_SYSCALLS|CONFIG_FUNCTION_GRAPH_TRACER' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sidy
- y
- built into the kernel image on every flavour - only a patch removes it
- Build switches
- CONFIG_DYNAMIC_FTRACE, CONFIG_FTRACE_SYSCALLS, CONFIG_FUNCTION_GRAPH_TRACER
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-07-24 (3 months ago)source
- CVSS
- 8.1 high
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.57%, higher than 45.9% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- arch/x86
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.9 | 6.12.93 | 8093442a2d1d |
| 6.9 | 6.18.35 | d59cc66b7027 |
| 6.9 | 7.0.12 | 9edff632ca21 |
| 6.9 | 7.1 | a17dc12bfed8 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:NAttack vector, network
- With a dynamic ftrace/kprobe trampoline monitoring a receive-path function such as tcp_v4_rcv, an unauthenticated remote attacker reaches the faulty trampoline by sending a valid network packet.
- AC:HAttack complexity, high
- Exploitation requires an affected Intel x86 platform using the non-default retbleed=stuff mitigation and an active dynamic trampoline on attacker-reachable code, conditions normally outside the attacker's control.
- PR:NPrivileges required, none
- In a preconfigured network-monitoring deployment, the attacker only sends packets and needs no credentials. Creating the probe is privileged through tracefs DAC or init-namespace capabilities, but deployed observability infrastructure can establish it beforehand.
- UI:NUser interaction, none
- Tracing may be enabled automatically by deployed monitoring infrastructure, and no human action is required when the attacker triggers the traced function.
- S:UScope, unchanged
- The erroneous access and resulting compromise occur within the host kernel's existing security authority without crossing a VM, IOMMU, or other scope boundary.
- C:HConfidentiality impact, high
- The stale displacement causes an out-of-bounds 8-byte read-modify-write that can land in mapped direct-map RAM on sufficiently large systems; corruption of kernel objects can plausibly enable code execution and arbitrary kernel-memory disclosure.
- I:HIntegrity impact, high
- The sarq instruction writes to unrelated direct-map memory, and repeated invocations can corrupt kernel objects or control data, potentially enabling kernel control-flow hijacking.
- A:HAvailability impact, high
- The documented first invocation produces a supervisor write page fault followed by a fatal kernel oops and panic, causing complete system unavailability.