CVE-2024-35917

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/bpf: Fix bpf_plt pointer arithmetic<br /> <br /> Kui-Feng Lee reported a crash on s390x triggered by the<br /> dummy_st_ops/dummy_init_ptr_arg test [1]:<br /> <br /> [] 0x2<br /> [] bpf_struct_ops_test_run+0x156/0x250<br /> [] __sys_bpf+0xa1a/0xd00<br /> [] __s390x_sys_bpf+0x44/0x50<br /> [] __do_syscall+0x244/0x300<br /> [] system_call+0x70/0x98<br /> <br /> This is caused by GCC moving memcpy() after assignments in<br /> bpf_jit_plt(), resulting in NULL pointers being written instead of<br /> the return and the target addresses.<br /> <br /> Looking at the GCC internals, the reordering is allowed because the<br /> alias analysis thinks that the memcpy() destination and the assignments&amp;#39;<br /> left-hand-sides are based on different objects: new_plt and<br /> bpf_plt_ret/bpf_plt_target respectively, and therefore they cannot<br /> alias.<br /> <br /> This is in turn due to a violation of the C standard:<br /> <br /> When two pointers are subtracted, both shall point to elements of the<br /> same array object, or one past the last element of the array object<br /> ...<br /> <br /> From the C&amp;#39;s perspective, bpf_plt_ret and bpf_plt are distinct objects<br /> and cannot be subtracted. In the practical terms, doing so confuses the<br /> GCC&amp;#39;s alias analysis.<br /> <br /> The code was written this way in order to let the C side know a few<br /> offsets defined in the assembly. While nice, this is by no means<br /> necessary. Fix the noncompliance by hardcoding these offsets.<br /> <br /> [1] https://lore.kernel.org/bpf/c9923c1d-971d-4022-8dc8-1364e929d34c@gmail.com/