CVE-2026-97420

In the Linux kernel, the following vulnerability has been resolved:

bpf: NUL-terminate replaced sysctl value

When writing to sysctls, proc sys call handler() guarantees that the buffer passed to proc handlers is NUL-terminated. If bpf sysctl set new value() replaces the pending sysctl value, it can hand a replacement buffer directly to proc handlers. However, the helper currently copies only buf len bytes into that buffer without appending a NUL terminator, leaving downstream parsers vulnerable to out-of-bounds access.

Fix this by appending a '0' after the replaced value to restore the expected sysctl semantics. Since the helper already rejects buf len greater than PAGE SIZE - 1, there is always room for the extra byte.

Reproduced in a QEMU x86 64 guest booted with KASAN while exercising the sysctl replacement path with a cgroup/sysctl BPF program. The reproducer targets /proc/sys/net/core/flow limit cpu bitmap, fills the original user write buffer with non-zero bytes, and overrides the sysctl value so the replacement buffer lacks a terminating NUL. Under that setup, the pre-fix kernel reported:

BUG: KASAN: slab-out-of-bounds in strnchrnul+0x72/0x90 Read of size 1 at addr ffff88800de57000 by task repro patch3/66 CPU: 0 UID: 0 PID: 66 Comm: repro patch3 Not tainted 7.1.0-rc3-00269-g8370ca1f87cc #6 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump stack lvl+0x68/0xa0 print report+0xcb/0x5e0 ? virt addr valid+0x21d/0x3f0 ? strnchrnul+0x72/0x90 ? strnchrnul+0x72/0x90 kasan report+0xca/0x100 ? strnchrnul+0x72/0x90 strnchrnul+0x72/0x90 bitmap parse+0x37/0x2e0 flow limit cpu sysctl+0xc6/0x840 ? pfx flow limit cpu sysctl+0x10/0x10 ? kvmalloc node noprof+0x5ba/0x870 proc sys call handler+0x31d/0x480 ? pfx proc sys call handler+0x10/0x10 ? selinux file permission+0x39f/0x500 ? lock is held type+0x9e/0x120 vfs write+0x98e/0x1000 ... The buggy address is located 0 bytes to the right of allocated 4096-byte region [ffff88800de56000, ffff88800de57000) With this fix applied, rerunning the same sysctl-targeted path yields no corresponding KASAN reports.