CVE-2026-64235

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/ftrace: Relocate %rip-relative percpu refs in dynamic trampolines<br /> <br /> With CONFIG_CALL_DEPTH_TRACKING enabled on an x86 retbleed-affected platform<br /> (eg: Skylake), with retbleed=stuff, registering a dynamic ftrace trampoline<br /> crashes on the first call into the traced function:<br /> <br /> BUG: unable to handle page fault for address: ffff88817ae18880<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> PGD 4b53067 P4D 4b53067 PUD 0<br /> Oops: Oops: 0002 [#1] SMP PTI<br /> CPU: 3 UID: 0 PID: 187 Comm: usleep Not tainted 7.0.10 #243 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014<br /> 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 48 c1 3d 1f a8 b6 02 05 48 8b 15 f6 00 00 00 4c 89 3c 24 4c 89<br /> Call Trace:<br /> <br /> ? find_held_lock<br /> ? exc_page_fault<br /> ? lock_release<br /> ? __x64_sys_clock_nanosleep<br /> ? lockdep_hardirqs_on_prepare<br /> ? trace_hardirqs_on<br /> __x64_sys_clock_nanosleep<br /> do_syscall_64<br /> ? exc_page_fault<br /> ? call_depth_return_thunk<br /> entry_SYSCALL_64_after_hwframe<br /> ...<br /> Kernel panic - not syncing: Fatal exception<br /> <br /> This small reproducer allows to easily trigger the crash:<br /> <br /> # echo &amp;#39;p __x64_sys_clock_nanosleep&amp;#39; &gt; /sys/kernel/tracing/kprobe_events<br /> # echo 1 &gt; /sys/kernel/tracing/events/kprobes/p___x64_sys_clock_nanosleep_0/enable<br /> # usleep 1<br /> <br /> Monitoring the crash under GDB points to the exact instruction in charge of<br /> incrementing the call depth:<br /> <br /> sarq $5, %gs:__x86_call_depth(%rip)<br /> <br /> This instruction matches the one inserted by the ftrace_regs_caller from<br /> ftrace_64.S. This emitted code was likely working fine until the introduction<br /> of<br /> <br /> 59bec00ace28 ("x86/percpu: Introduce %rip-relative addressing to PER_CPU_VAR()"):<br /> <br /> it has made the call depth accounting addressing relative to $rip, instead of<br /> being based on an absolute address.<br /> <br /> As this code exact location depends on where the trampoline lives in memory,<br /> the corresponding displacement needs to be adjusted at runtime to actually<br /> correctly find the per-cpu __x86_call_depth value, otherwise the targeted<br /> address is wrong, leading to the page fault seen above.<br /> <br /> Fix the %rip-relative displacement of the copied CALL_DEPTH_ACCOUNT<br /> instruction (from ftrace_regs_caller) by calling text_poke_apply_relocation(),<br /> as it is done for example by the x86 BPF JIT compiler through<br /> x86_call_depth_emit_accounting(). This corrects both CALL_DEPTH_ACCOUNT slots,<br /> in ftrace_caller and ftrace_regs_caller.<br /> <br /> [ bp: Massage. ]