CVE-2026-63809 in Linux
Tóm tắt
Bởi VulDB • 19/07/2026
Trong kernel Linux, lỗ hổng sau đây đã được khắc phục:
bpf: sử dụng kvfree() cho bộ đệm ghi sysctl thay thế
proc_sys_call_handler() phân bổ bộ đệm sysctl tạm thời của nó bằng kvzalloc() và chuyển nó đến __cgroup_bpf_run_filter_sysctl(). Vì kvzalloc() có thể quay lại vmalloc() đối với các yêu cầu cấp phát lớn, việc giải phóng bộ đệm đó bằng kfree() là sai lầm và có thể làm hỏng dữ liệu trong bộ nhớ.
Sử dụng kvfree() để xử lý an toàn cả hai loại phân bổ kmalloc và kvzalloc()/vmalloc.
Lỗi này lần đầu tiên được cảnh báo bởi một công cụ phân tích thử nghiệm mà chúng tôi đang phát triển cho các lỗi quản lý bộ nhớ kernel, khi phân tích phiên bản v6.13-rc1. Công cụ vẫn đang trong quá trình phát triển và chưa sẵn sàng sử dụng rộng rãi. Việc kiểm tra thủ công xác nhận rằng lỗ hổng này vẫn còn tồn tại trong v7.1-rc5.
Đã tái tạo lỗi dựa trên v7.1-rc4 trong một máy khách QEMU x86_64 khởi động với KASAN và CONFIG_FAILSLAB được bật. Để kích hoạt đường dẫn thay thế, cây kiểm thử cũng bao gồm bản sửa đổi đi kèm cho việc kiểm tra ret == 1 cũ trong __cgroup_bpf_run_filter_sysctl(). Trình tái tạo giới hạn các lần tiêm failslab vào phạm vi proc_sys_call_handler(), sử dụng stacktrace-depth=32 và tiêm fail-nth=1 khi ghi 8191 byte vào /proc/sys/kernel/domainname từ một tiến trình trong cgroup mục tiêu. Với cấu hình đó, fail-nth=1 đã kích hoạt lỗi:
BUG: unable to handle page fault for address: ffffeb0200024d48 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 SMP KASAN NOPTI CPU: 2 UID: 0 PID: 209 Comm: repro_proc_sys_ Not tainted 7.1.0-rc4-00686-g97625979a5d4 PREEMPT(lazy) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 RIP: 0010:kfree+0x6e/0x510 ... Call Trace: <TASK> ? __cgroup_bpf_run_filter_sysctl+0x626/0xc30 __cgroup_bpf_run_filter_sysctl+0x74d/0xc30 ? __pfx___cgroup_bpf_run_filter_sysctl+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? __kvmalloc_node_noprof+0x345/0x870 ? proc_sys_call_handler+0x250/0x480 ? srso_return_thunk+0x5/0x5f proc_sys_call_handler+0x3a2/0x480 ? __pfx_proc_sys_call_handler+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? selinux_file_permission+0x39f/0x500 ? srso_return_thunk+0x5/0x5f ? lock_is_held_type+0x9e/0x
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.