Bug 1220923 (CVE-2023-52521)

Summary: VUL-0: CVE-2023-52521: kernel: bpf: Annotate bpf_long_memcpy with data_race
Product: [Novell Products] SUSE Security Incidents Reporter: SMASH SMASH <smash_bz>
Component: IncidentsAssignee: Security Team bot <security-team>
Status: RESOLVED INVALID QA Contact: Security Team bot <security-team>
Severity: Normal    
Priority: P3 - Medium CC: gabriele.sonnu, mhocko, shung-hsi.yu
Version: unspecified   
Target Milestone: ---   
Hardware: Other   
OS: Other   
URL: https://smash.suse.de/issue/396070/
Whiteboard: CVSSv3.1:SUSE:CVE-2023-52521:5.5:(AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Found By: Security Response Team Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description SMASH SMASH 2024-03-05 09:17:45 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
Comment 1 Gabriele Sonnu 2024-03-05 09:41:03 UTC 
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.
Comment 2 Shung-Hsi Yu 2024-03-05 10:17:02 UTC 
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/
Comment 3 Michal Hocko 2024-03-05 10:51:35 UTC 
(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?
Comment 5 Shung-Hsi Yu 2024-03-06 07:38:30 UTC 
CVE has been rejected[1]. Reassigning back to security team.

1: https://lore.kernel.org/all/2024030519-REJECTED-22f6@gregkh/
Comment 6 Gabriele Sonnu 2024-03-06 14:41:07 UTC 
Thanks, updated our tracking. Closing this.