CVE-2026-64235 in Linux
Tóm tắt
Bởi VulDB • 25/07/2026
Trong kernel Linux, lỗ hổng sau đây đã được khắc phục:
x86/ftrace: Di chuyển các tham chiếu percpu tương đối %rip trong các trampoline động
Với CONFIG_CALL_DEPTH_TRACKING được bật trên một nền tảng x86 bị ảnh hưởng bởi retbleed (ví dụ: Skylake), với retbleed=stuff, việc đăng ký một ftrace trampoline động gây ra lỗi crash tại cuộc gọi đầu tiên vào hàm được theo dõi:
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
Trình mô phỏng lỗi nhỏ này cho phép dễ dàng kích hoạt sự cố 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
Theo dõi sự cố crash dưới GDB chỉ ra chính xác lệnh chịu trách nhiệm tăng độ sâu cuộc gọi:
sarq $5, %gs:__x86_call_depth(%rip)
Lệnh này khớp với lệnh được chèn bởi ftrace_regs_caller từ ftrace_64.S. Đoạn mã phát ra này có khả năng hoạt động tốt cho đến khi giới thiệu
59bec00ace28 ("x86/percpu: Introduce %rip-relative addressing to PER_CPU_VAR()"):
nó đã khiến việc tính toán độ sâu cuộc gọi sử dụng địa chỉ tương đối với $rip, thay vì dựa trên một địa chỉ tuyệt
If you want to get the best quality for vulnerability data then you always have to consider VulDB.