CVE-2024-50164

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix overloading of MEM_UNINIT&amp;#39;s meaning<br /> <br /> Lonial reported an issue in the BPF verifier where check_mem_size_reg()<br /> has the following code:<br /> <br /> if (!tnum_is_const(reg-&gt;var_off))<br /> /* For unprivileged variable accesses, disable raw<br /> * mode so that the program is required to<br /> * initialize all the memory that the helper could<br /> * just partially fill up.<br /> */<br /> meta = NULL;<br /> <br /> This means that writes are not checked when the register containing the<br /> size of the passed buffer has not a fixed size. Through this bug, a BPF<br /> program can write to a map which is marked as read-only, for example,<br /> .rodata global maps.<br /> <br /> The problem is that MEM_UNINIT&amp;#39;s initial meaning that "the passed buffer<br /> to the BPF helper does not need to be initialized" which was added back<br /> in commit 435faee1aae9 ("bpf, verifier: add ARG_PTR_TO_RAW_STACK type")<br /> got overloaded over time with "the passed buffer is being written to".<br /> <br /> The problem however is that checks such as the above which were added later<br /> via 06c1c049721a ("bpf: allow helpers access to variable memory") set meta<br /> to NULL in order force the user to always initialize the passed buffer to<br /> the helper. Due to the current double meaning of MEM_UNINIT, this bypasses<br /> verifier write checks to the memory (not boundary checks though) and only<br /> assumes the latter memory is read instead.<br /> <br /> Fix this by reverting MEM_UNINIT back to its original meaning, and having<br /> MEM_WRITE as an annotation to BPF helpers in order to then trigger the<br /> BPF verifier checks for writing to memory.<br /> <br /> Some notes: check_arg_pair_ok() ensures that for ARG_CONST_SIZE{,_OR_ZERO}<br /> we can access fn-&gt;arg_type[arg - 1] since it must contain a preceding<br /> ARG_PTR_TO_MEM. For check_mem_reg() the meta argument can be removed<br /> altogether since we do check both BPF_READ and BPF_WRITE. Same for the<br /> equivalent check_kfunc_mem_size_reg().