CVE-2026-63809 in Linux
Riassunto
di VulDB • 19/07/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
bpf: utilizzare kvfree() per il buffer di scrittura sysctl sostituito
proc_sys_call_handler() alloca il proprio buffer temporaneo sysctl con kvzalloc() e lo passa a __cgroup_bpf_run_filter_sysctl(). Poiché kvzalloc() può ricorrere a vmalloc() per allocazioni di grandi dimensioni, liberare tale buffer utilizzando kfree() è errato e può causare corruzione della memoria.
Utilizzare kvfree() per gestire in modo sicuro sia le allocazioni con kmalloc che quelle con kvzalloc()/vmalloc.
Il bug è stato segnalato inizialmente da uno strumento di analisi sperimentale sviluppato per rilevare bug nella gestione della memoria del kernel, durante l'analisi della versione v6.13-rc1. Lo strumento è ancora in fase di sviluppo e non è attualmente disponibile al pubblico. L'ispezione manuale conferma che il bug è ancora presente nella versione v7.1-rc5.
Il bug è stato riprodotto sulla base della versione v7.1-rc4 in un guest QEMU x86_64 avviato con KASAN e CONFIG_FAILSLAB abilitati. Per testare il percorso di sostituzione, l'albero dei test includeva anche la correzione accompagnatoria per il controllo obsoleto ret == 1 in __cgroup_bpf_run_filter_sysctl(). Il riproduttore limita le iniezioni failslab all'intervallo proc_sys_call_handler(), utilizza stacktrace-depth=32 e inietta fail-nth=1 durante la scrittura di 8191 byte su /proc/sys/kernel/domainname da un task nel cgroup target. Con questa configurazione, fail-nth=1 ha innescato il fault:
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/0x120
If you want to get the best quality for vulnerability data then you always have to consider VulDB.