cbcvebase.
CVE-2021-47608
published 2024-06-19

CVE-2021-47608: In the Linux kernel, the following vulnerability has been resolved: bpf: Fix kernel address leakage in atomic fetch The change in commit 37086bfdc737 ("bpf…

PriorityP424medium5.5CVSS 3.1
AVLACLPRLUINSUCHINAN
EPSS
0.21%
11.4th percentile
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix kernel address leakage in atomic fetch The change in commit 37086bfdc737 ("bpf: Propagate stack bounds to registers in atomics w/ BPF_FETCH") around check_mem_access() handling is buggy since this would allow for unprivileged users to leak kernel pointers. For example, an atomic fetch/and with -1 on a stack destination which holds a spilled pointer will migrate the spilled register type into a scalar, which can then be exported out of the program (since scalar != pointer) by dumping it into a map value. The original implementation of XADD was preventing this situation by using a double call to check_mem_access() one with BPF_READ and a subsequent one with BPF_WRITE, in both cases passing -1 as a placeholder value instead of register as per XADD semantics since it didn't contain a value fetch. The BPF_READ also included a check in check_stack_read_fixed_off() which rejects the program if the stack slot is of __is_pointer_value() if dst_regno < 0. The latter is to distinguish whether we're dealing with a regular stack spill/ fill or some arithmetical operation which is disallowed on non-scalars, see also 6e7e63cbb023 ("bpf: Forbid XADD on spilled pointers for unprivileged users") for more context on check_mem_access() and its handling of placeholder value -1. One minimally intrusive option to fix the leak is for the BPF_FETCH case to initially check the BPF_READ case via check_mem_access() with -1 as register, followed by the actual load case with non-negative load_reg to propagate stack bounds to registers.

Affected

9 ranges
VendorProductVersion rangeFixed in
debianlinux< linux 5.15.15-1 (bookworm)linux 5.15.15-1 (bookworm)
linuxlinux
linuxlinux>= 37086bfdc737ea6f66bf68dcf16757004d68e1e1 < 423628125a484538111c2c6d9bb1588eb086053b423628125a484538111c2c6d9bb1588eb086053b
linuxlinux>= 37086bfdc737ea6f66bf68dcf16757004d68e1e1 < 7d3baf0afa3aa9102d6a521a8e4c41888bb798827d3baf0afa3aa9102d6a521a8e4c41888bb79882
linuxlinux_kernel
linuxlinux_kernel>= 0 < 5.15.15-15.15.15-1
linuxlinux_kernel>= 0 < 5.15.15-15.15.15-1
linuxlinux_kernel>= 0 < 5.15.15-15.15.15-1
linuxlinux_kernel>= 5.12 < 5.15.115.15.11

CVSS provenance

nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.