Wind River Support Network

Description

In the Linux kernel, the following vulnerability has been resolved:[EOL][EOL]bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO[EOL][EOL]Precision markers need to be propagated whenever we have an ARG_CONST_*[EOL]style argument, as the verifier cannot consider imprecise scalars to be[EOL]equivalent for the purposes of states_equal check when such arguments[EOL]refine the return value (in this case, set mem_size for PTR_TO_MEM). The[EOL]resultant mem_size for the R0 is derived from the constant value, and if[EOL]the verifier incorrectly prunes states considering them equivalent where[EOL]such arguments exist (by seeing that both registers have reg->precise as[EOL]false in regsafe), we can end up with invalid programs passing the[EOL]verifier which can do access beyond what should have been the correct[EOL]mem_size in that explored state.[EOL][EOL]To show a concrete example of the problem:[EOL][EOL]0000000000000000 <prog>:[EOL]       0:       r2 = *(u32 *)(r1 + 80)[EOL]       1:       r1 = *(u32 *)(r1 + 76)[EOL]       2:       r3 = r1[EOL]       3:       r3 += 4[EOL]       4:       if r3 > r2 goto +18 <LBB5_5>[EOL]       5:       w2 = 0[EOL]       6:       *(u32 *)(r1 + 0) = r2[EOL]       7:       r1 = *(u32 *)(r1 + 0)[EOL]       8:       r2 = 1[EOL]       9:       if w1 == 0 goto +1 <LBB5_3>[EOL]      10:       r2 = -1[EOL][EOL]0000000000000058 <LBB5_3>:[EOL]      11:       r1 = 0 ll[EOL]      13:       r3 = 0[EOL]      14:       call bpf_ringbuf_reserve[EOL]      15:       if r0 == 0 goto +7 <LBB5_5>[EOL]      16:       r1 = r0[EOL]      17:       r1 += 16777215[EOL]      18:       w2 = 0[EOL]      19:       *(u8 *)(r1 + 0) = r2[EOL]      20:       r1 = r0[EOL]      21:       r2 = 0[EOL]      22:       call bpf_ringbuf_submit[EOL][EOL]00000000000000b8 <LBB5_5>:[EOL]      23:       w0 = 0[EOL]      24:       exit[EOL][EOL]For the first case, the single line execution's exploration will prune[EOL]the search at insn 14 for the branch insn 9's second leg as it will be[EOL]verified first using r2 = -1 (UINT_MAX), while as w1 at insn 9 will[EOL]always be 0 so at runtime we don't get error for being greater than[EOL]UINT_MAX/4 from bpf_ringbuf_reserve. The verifier during regsafe just[EOL]sees reg->precise as false for both r2 registers in both states, hence[EOL]considers them equal for purposes of states_equal.[EOL][EOL]If we propagated precise markers using the backtracking support, we[EOL]would use the precise marking to then ensure that old r2 (UINT_MAX) was[EOL]within the new r2 (1) and this would never be true, so the verification[EOL]would rightfully fail.[EOL][EOL]The end result is that the out of bounds access at instruction 19 would[EOL]be permitted without this fix.[EOL][EOL]Note that reg->precise is always set to true when user does not have[EOL]CAP_BPF (or when subprog count is greater than 1 (i.e. use of any static[EOL]or global functions)), hence this is only a problem when precision marks[EOL]need to be explicitly propagated (i.e. privileged users with CAP_BPF).[EOL][EOL]A simplified test case has been included in the next patch to prevent[EOL]future regressions.