CVE-2023-52452

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix accesses to uninit stack slots<br /> <br /> Privileged programs are supposed to be able to read uninitialized stack<br /> memory (ever since 6715df8d5) but, before this patch, these accesses<br /> were permitted inconsistently. In particular, accesses were permitted<br /> above state-&gt;allocated_stack, but not below it. In other words, if the<br /> stack was already "large enough", the access was permitted, but<br /> otherwise the access was rejected instead of being allowed to "grow the<br /> stack". This undesired rejection was happening in two places:<br /> - in check_stack_slot_within_bounds()<br /> - in check_stack_range_initialized()<br /> This patch arranges for these accesses to be permitted. A bunch of tests<br /> that were relying on the old rejection had to change; all of them were<br /> changed to add also run unprivileged, in which case the old behavior<br /> persists. One tests couldn&amp;#39;t be updated - global_func16 - because it<br /> can&amp;#39;t run unprivileged for other reasons.<br /> <br /> This patch also fixes the tracking of the stack size for variable-offset<br /> reads. This second fix is bundled in the same commit as the first one<br /> because they&amp;#39;re inter-related. Before this patch, writes to the stack<br /> using registers containing a variable offset (as opposed to registers<br /> with fixed, known values) were not properly contributing to the<br /> function&amp;#39;s needed stack size. As a result, it was possible for a program<br /> to verify, but then to attempt to read out-of-bounds data at runtime<br /> because a too small stack had been allocated for it.<br /> <br /> Each function tracks the size of the stack it needs in<br /> bpf_subprog_info.stack_depth, which is maintained by<br /> update_stack_depth(). For regular memory accesses, check_mem_access()<br /> was calling update_state_depth() but it was passing in only the fixed<br /> part of the offset register, ignoring the variable offset. This was<br /> incorrect; the minimum possible value of that register should be used<br /> instead.<br /> <br /> This tracking is now fixed by centralizing the tracking of stack size in<br /> grow_stack_state(), and by lifting the calls to grow_stack_state() to<br /> check_stack_access_within_bounds() as suggested by Andrii. The code is<br /> now simpler and more convincingly tracks the correct maximum stack size.<br /> check_stack_range_initialized() can now rely on enough stack having been<br /> allocated for the access; this helps with the fix for the first issue.<br /> <br /> A few tests were changed to also check the stack depth computation. The<br /> one that fails without this patch is verifier_var_off:stack_write_priv_vs_unpriv.