216.73.216.197

CVE-2021-47608

· Published 19/06/2024 15:15 · Modified 19/06/2024 15:15

Labels: CVE-2021-47608 2024-06-19416baaa9-dc9f-4396-8d5f-8c081fb06d67CVE-2021-47608

Essential information

Published
19/06/2024 15:15
Modified
19/06/2024 15:15
Author
Creator
CISA KEV
No
CWE

Description

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.

NVD status

Status
Received — CVE has been recently published to the CVE List and has been received by the NVD.
Source
416baaa9-dc9f-4396-8d5f-8c081fb06d67
NVD
View on NVD

References