2.4 KiB
CVE-2024-50164
Description
In the Linux kernel, the following vulnerability has been resolved:bpf: Fix overloading of MEM_UNINIT's meaningLonial reported an issue in the BPF verifier where check_mem_size_reg()has the following code: if (!tnum_is_const(reg->var_off)) /* For unprivileged variable accesses, disable raw * mode so that the program is required to * initialize all the memory that the helper could * just partially fill up. */ meta = NULL;This means that writes are not checked when the register containing thesize of the passed buffer has not a fixed size. Through this bug, a BPFprogram can write to a map which is marked as read-only, for example,.rodata global maps.The problem is that MEM_UNINIT's initial meaning that "the passed bufferto the BPF helper does not need to be initialized" which was added backin commit 435faee1aae9 ("bpf, verifier: add ARG_PTR_TO_RAW_STACK type")got overloaded over time with "the passed buffer is being written to".The problem however is that checks such as the above which were added latervia 06c1c049721a ("bpf: allow helpers access to variable memory") set metato NULL in order force the user to always initialize the passed buffer tothe helper. Due to the current double meaning of MEM_UNINIT, this bypassesverifier write checks to the memory (not boundary checks though) and onlyassumes the latter memory is read instead.Fix this by reverting MEM_UNINIT back to its original meaning, and havingMEM_WRITE as an annotation to BPF helpers in order to then trigger theBPF verifier checks for writing to memory.Some notes: check_arg_pair_ok() ensures that for ARG_CONST_SIZE{,_OR_ZERO}we can access fn->arg_type[arg - 1] since it must contain a precedingARG_PTR_TO_MEM. For check_mem_reg() the meta argument can be removedaltogether since we do check both BPF_READ and BPF_WRITE. Same for theequivalent check_kfunc_mem_size_reg().
POC
Reference
No PoCs from references.