CVE-2023-53790

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Zeroing allocated object from slab in bpf memory allocator<br /> <br /> Currently the freed element in bpf memory allocator may be immediately<br /> reused, for htab map the reuse will reinitialize special fields in map<br /> value (e.g., bpf_spin_lock), but lookup procedure may still access<br /> these special fields, and it may lead to hard-lockup as shown below:<br /> <br /> NMI backtrace for cpu 16<br /> CPU: 16 PID: 2574 Comm: htab.bin Tainted: G L 6.1.0+ #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),<br /> RIP: 0010:queued_spin_lock_slowpath+0x283/0x2c0<br /> ......<br /> Call Trace:<br /> <br /> copy_map_value_locked+0xb7/0x170<br /> bpf_map_copy_value+0x113/0x3c0<br /> __sys_bpf+0x1c67/0x2780<br /> __x64_sys_bpf+0x1c/0x20<br /> do_syscall_64+0x30/0x60<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> ......<br /> <br /> <br /> For htab map, just like the preallocated case, these is no need to<br /> initialize these special fields in map value again once these fields<br /> have been initialized. For preallocated htab map, these fields are<br /> initialized through __GFP_ZERO in bpf_map_area_alloc(), so do the<br /> similar thing for non-preallocated htab in bpf memory allocator. And<br /> there is no need to use __GFP_ZERO for per-cpu bpf memory allocator,<br /> because __alloc_percpu_gfp() does it implicitly.