Bugzilla – Bug 1220923
VUL-0: CVE-2023-52521: kernel: bpf: Annotate bpf_long_memcpy with data_race
Last modified: 2024-03-06 14:41:07 UTC
In the Linux kernel, the following vulnerability has been resolved: bpf: Annotate bpf_long_memcpy with data_race syzbot reported a data race splat between two processes trying to update the same BPF map value via syscall on different CPUs: BUG: KCSAN: data-race in bpf_percpu_array_update / bpf_percpu_array_update write to 0xffffe8fffe7425d8 of 8 bytes by task 8257 on cpu 1: bpf_long_memcpy include/linux/bpf.h:428 [inline] bpf_obj_memcpy include/linux/bpf.h:441 [inline] copy_map_value_long include/linux/bpf.h:464 [inline] bpf_percpu_array_update+0x3bb/0x500 kernel/bpf/arraymap.c:380 bpf_map_update_value+0x190/0x370 kernel/bpf/syscall.c:175 generic_map_update_batch+0x3ae/0x4f0 kernel/bpf/syscall.c:1749 bpf_map_do_batch+0x2df/0x3d0 kernel/bpf/syscall.c:4648 __sys_bpf+0x28a/0x780 __do_sys_bpf kernel/bpf/syscall.c:5241 [inline] __se_sys_bpf kernel/bpf/syscall.c:5239 [inline] __x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5239 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd write to 0xffffe8fffe7425d8 of 8 bytes by task 8268 on cpu 0: bpf_long_memcpy include/linux/bpf.h:428 [inline] bpf_obj_memcpy include/linux/bpf.h:441 [inline] copy_map_value_long include/linux/bpf.h:464 [inline] bpf_percpu_array_update+0x3bb/0x500 kernel/bpf/arraymap.c:380 bpf_map_update_value+0x190/0x370 kernel/bpf/syscall.c:175 generic_map_update_batch+0x3ae/0x4f0 kernel/bpf/syscall.c:1749 bpf_map_do_batch+0x2df/0x3d0 kernel/bpf/syscall.c:4648 __sys_bpf+0x28a/0x780 __do_sys_bpf kernel/bpf/syscall.c:5241 [inline] __se_sys_bpf kernel/bpf/syscall.c:5239 [inline] __x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5239 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0x0000000000000000 -> 0xfffffff000002788 The bpf_long_memcpy is used with 8-byte aligned pointers, power-of-8 size and forced to use long read/writes to try to atomically copy long counters. It is best-effort only and no barriers are here since it _will_ race with concurrent updates from BPF programs. The bpf_long_memcpy() is called from bpf(2) syscall. Marco suggested that the best way to make this known to KCSAN would be to use data_race() annotation. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-52521 https://git.kernel.org/stable/c/5685f8a6fae1fbe480493b980a1fdbe67c86a094 https://git.kernel.org/stable/c/6a86b5b5cd76d2734304a0173f5f01aa8aa2025e https://git.kernel.org/stable/c/e562de67dc9196f2415f117796a2108c00ac7fc6 https://www.cve.org/CVERecord?id=CVE-2023-52521 https://bugzilla.redhat.com/show_bug.cgi?id=2267796
Affected code found in: - SLE12-SP5 - SLE15-SP4 - SLE15-SP5 - cve/linux-4.12 - cve/linux-5.3 stable and SLE15-SP6 already contain the fixing commit (5685f8a6fae1), so tracking above branches as affected.
This doesn't look like a vulnerability per se. The data race seems to be by designed[1], and the reference fixing commit only annotates the code expecting data race so KCSAN does not emit warning, with no behavioral change. 1: https://lore.kernel.org/bpf/2e260b7c-2a89-2d0c-afb5-708c34230db2@linux.dev/
(In reply to Shung-Hsi Yu from comment #2) > This doesn't look like a vulnerability per se. The data race seems to be by > designed[1], and the reference fixing commit only annotates the code > expecting data race so KCSAN does not emit warning, with no behavioral > change. > > 1: > https://lore.kernel.org/bpf/2e260b7c-2a89-2d0c-afb5-708c34230db2@linux.dev/ Completely agreed. This should be disputed. The patch has no meaning outside of KCSAN. Shung-Hsi Yu do you want to do that or should I?
CVE has been rejected[1]. Reassigning back to security team. 1: https://lore.kernel.org/all/2024030519-REJECTED-22f6@gregkh/
Thanks, updated our tracking. Closing this.