1. 11 May, 2021 2 commits
    • Thadeu Lima de Souza Cascardo's avatar
      bpf, ringbuf: Deny reserve of buffers larger than ringbuf · 4b81cceb
      Thadeu Lima de Souza Cascardo authored
      A BPF program might try to reserve a buffer larger than the ringbuf size.
      If the consumer pointer is way ahead of the producer, that would be
      successfully reserved, allowing the BPF program to read or write out of
      the ringbuf allocated area.
      
      Reported-by: Ryota Shiga (Flatt Security)
      Fixes: 457f4436 ("bpf: Implement BPF ring buffer and verifier support for it")
      Signed-off-by: default avatarThadeu Lima de Souza Cascardo <cascardo@canonical.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      4b81cceb
    • Daniel Borkmann's avatar
      bpf: Fix alu32 const subreg bound tracking on bitwise operations · 049c4e13
      Daniel Borkmann authored
      Fix a bug in the verifier's scalar32_min_max_*() functions which leads to
      incorrect tracking of 32 bit bounds for the simulation of and/or/xor bitops.
      When both the src & dst subreg is a known constant, then the assumption is
      that scalar_min_max_*() will take care to update bounds correctly. However,
      this is not the case, for example, consider a register R2 which has a tnum
      of 0xffffffff00000000, meaning, lower 32 bits are known constant and in this
      case of value 0x00000001. R2 is then and'ed with a register R3 which is a
      64 bit known constant, here, 0x100000002.
      
      What can be seen in line '10:' is that 32 bit bounds reach an invalid state
      where {u,s}32_min_value > {u,s}32_max_value. The reason is scalar32_min_max_*()
      delegates 32 bit bounds updates to scalar_min_max_*(), however, that really
      only takes place when both the 64 bit src & dst register is a known constant.
      Given scalar32_min_max_*() is intended to be designed as closely as possible
      to scalar_min_max_*(), update the 32 bit bounds in this situation through
      __mark_reg32_known() which will set all {u,s}32_{min,max}_value to the correct
      constant, which is 0x00000000 after the fix (given 0x00000001 & 0x00000002 in
      32 bit space). This is possible given var32_off already holds the final value
      as dst_reg->var_off is updated before calling scalar32_min_max_*().
      
      Before fix, invalid tracking of R2:
      
        [...]
        9: R0_w=inv1337 R1=ctx(id=0,off=0,imm=0) R2_w=inv(id=0,smin_value=-9223372036854775807 (0x8000000000000001),smax_value=9223372032559808513 (0x7fffffff00000001),umin_value=1,umax_value=0xffffffff00000001,var_off=(0x1; 0xffffffff00000000),s32_min_value=1,s32_max_value=1,u32_min_value=1,u32_max_value=1) R3_w=inv4294967298 R10=fp0
        9: (5f) r2 &= r3
        10: R0_w=inv1337 R1=ctx(id=0,off=0,imm=0) R2_w=inv(id=0,smin_value=0,smax_value=4294967296 (0x100000000),umin_value=0,umax_value=0x100000000,var_off=(0x0; 0x100000000),s32_min_value=1,s32_max_value=0,u32_min_value=1,u32_max_value=0) R3_w=inv4294967298 R10=fp0
        [...]
      
      After fix, correct tracking of R2:
      
        [...]
        9: R0_w=inv1337 R1=ctx(id=0,off=0,imm=0) R2_w=inv(id=0,smin_value=-9223372036854775807 (0x8000000000000001),smax_value=9223372032559808513 (0x7fffffff00000001),umin_value=1,umax_value=0xffffffff00000001,var_off=(0x1; 0xffffffff00000000),s32_min_value=1,s32_max_value=1,u32_min_value=1,u32_max_value=1) R3_w=inv4294967298 R10=fp0
        9: (5f) r2 &= r3
        10: R0_w=inv1337 R1=ctx(id=0,off=0,imm=0) R2_w=inv(id=0,smin_value=0,smax_value=4294967296 (0x100000000),umin_value=0,umax_value=0x100000000,var_off=(0x0; 0x100000000),s32_min_value=0,s32_max_value=0,u32_min_value=0,u32_max_value=0) R3_w=inv4294967298 R10=fp0
        [...]
      
      Fixes: 3f50f132 ("bpf: Verifier, do explicit ALU32 bounds tracking")
      Fixes: 2921c90d ("bpf: Fix a verifier failure with xor")
      Reported-by: Manfred Paul (@_manfp)
      Reported-by: default avatarThadeu Lima de Souza Cascardo <cascardo@canonical.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Reviewed-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      049c4e13
  2. 06 May, 2021 2 commits
  3. 05 May, 2021 1 commit
  4. 04 May, 2021 1 commit
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf · 1682d8df
      David S. Miller authored
      Daniel Borkmann says:
      
      ====================
      pull-request: bpf 2021-05-04
      
      The following pull-request contains BPF updates for your *net* tree.
      
      We've added 5 non-merge commits during the last 4 day(s) which contain
      a total of 6 files changed, 52 insertions(+), 30 deletions(-).
      
      The main changes are:
      
      1) Fix libbpf overflow when processing BPF ring buffer in case of extreme
         application behavior, from Brendan Jackman.
      
      2) Fix potential data leakage of uninitialized BPF stack under speculative
         execution, from Daniel Borkmann.
      
      3) Fix off-by-one when validating xsk pool chunks, from Xuan Zhuo.
      
      4) Fix snprintf BPF selftest with a pid filter to avoid racing its output
         test buffer, from Florent Revest.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1682d8df
  5. 03 May, 2021 15 commits
  6. 30 Apr, 2021 16 commits
  7. 29 Apr, 2021 3 commits