Date:   Wed, 15 Jan 2020 13:41:04 -0800
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Yonghong Song <yhs@...com>
Cc:     Daniel Borkmann <daniel@...earbox.net>,
        "ast@...nel.org" <ast@...nel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
        "anatoly.trosinenko@...il.com" <anatoly.trosinenko@...il.com>
Subject: Re: [PATCH bpf] bpf: Fix incorrect verifier simulation of ARSH under ALU32

On Wed, Jan 15, 2020 at 1:31 PM Yonghong Song <yhs@...com> wrote:
>
>
>
> On 1/15/20 12:47 PM, Daniel Borkmann wrote:
> > Anatoly has been fuzzing with kBdysch harness and reported a hang in one
> > of the outcomes:
> >
> >    0: R1=ctx(id=0,off=0,imm=0) R10=fp0
> >    0: (85) call bpf_get_socket_cookie#46
> >    1: R0_w=invP(id=0) R10=fp0
> >    1: (57) r0 &= 808464432
> >    2: R0_w=invP(id=0,umax_value=808464432,var_off=(0x0; 0x30303030)) R10=fp0
> >    2: (14) w0 -= 810299440
> >    3: R0_w=invP(id=0,umax_value=4294967295,var_off=(0xcf800000; 0x3077fff0)) R10=fp0
> >    3: (c4) w0 s>>= 1
> >    4: R0_w=invP(id=0,umin_value=1740636160,umax_value=2147221496,var_off=(0x67c00000; 0x183bfff8)) R10=fp0
> >    4: (76) if w0 s>= 0x30303030 goto pc+216
> >    221: R0_w=invP(id=0,umin_value=1740636160,umax_value=2147221496,var_off=(0x67c00000; 0x183bfff8)) R10=fp0
> >    221: (95) exit
> >    processed 6 insns (limit 1000000) [...]
> >
> > Taking a closer look, the program was xlated as follows:
> >
> >    # ./bpftool p d x i 12
> >    0: (85) call bpf_get_socket_cookie#7800896
> >    1: (bf) r6 = r0
> >    2: (57) r6 &= 808464432
> >    3: (14) w6 -= 810299440
> >    4: (c4) w6 s>>= 1
> >    5: (76) if w6 s>= 0x30303030 goto pc+216
> >    6: (05) goto pc-1
> >    7: (05) goto pc-1
> >    8: (05) goto pc-1
> >    [...]
> >    220: (05) goto pc-1
> >    221: (05) goto pc-1
> >    222: (95) exit
> >
> > Meaning, the visible effect is very similar to f54c7898ed1c ("bpf: Fix
> > precision tracking for unbounded scalars"), that is, the fall-through
> > branch in the instruction 5 is considered to be never taken given the
> > conclusion from the min/max bounds tracking in w6, and therefore the
> > dead-code sanitation rewrites it as goto pc-1. However, real-life input
> > disagrees with verification analysis since a soft-lockup was observed.
> >
> > The bug sits in the analysis of the ARSH. The definition is that we shift
> > the target register value right by K bits through shifting in copies of
> > its sign bit. In adjust_scalar_min_max_vals(), we do first coerce the
> > register into 32 bit mode, same happens after simulating the operation.
> > However, for the case of simulating the actual ARSH, we don't take the
> > mode into account and act as if it's always 64 bit, but location of sign
> > bit is different:
> >
> >    dst_reg->smin_value >>= umin_val;
> >    dst_reg->smax_value >>= umin_val;
> >    dst_reg->var_off = tnum_arshift(dst_reg->var_off, umin_val);
> >
> > Consider an unknown R0 where bpf_get_socket_cookie() (or others) would
> > for example return 0xffff. With the above ARSH simulation, we'd see the
> > following results:
> >
> >    [...]
> >    1: R1=ctx(id=0,off=0,imm=0) R2_w=invP65535 R10=fp0
> >    1: (85) call bpf_get_socket_cookie#46
> >    2: R0_w=invP(id=0) R10=fp0
> >    2: (57) r0 &= 808464432
> >      -> R0_runtime = 0x3030
> >    3: R0_w=invP(id=0,umax_value=808464432,var_off=(0x0; 0x30303030)) R10=fp0
> >    3: (14) w0 -= 810299440
> >      -> R0_runtime = 0xcfb40000
> >    4: R0_w=invP(id=0,umax_value=4294967295,var_off=(0xcf800000; 0x3077fff0)) R10=fp0
> >                                (0xffffffff)
> >    4: (c4) w0 s>>= 1
> >      -> R0_runtime = 0xe7da0000
> >    5: R0_w=invP(id=0,umin_value=1740636160,umax_value=2147221496,var_off=(0x67c00000; 0x183bfff8)) R10=fp0
> >                                (0x67c00000)           (0x7ffbfff8)
> >    [...]
> >
> > In insn 3, we have a runtime value of 0xcfb40000, which is '1100 1111 1011
> > 0100 0000 0000 0000 0000', the result after the shift has 0xe7da0000 that
> > is '1110 0111 1101 1010 0000 0000 0000 0000', where the sign bit is correctly
> > retained in 32 bit mode. In insn4, the umax was 0xffffffff, and changed into
> > 0x7ffbfff8 after the shift, that is, '0111 1111 1111 1011 1111 1111 1111 1000'
> > and means here that the simulation didn't retain the sign bit. With above
> > logic, the updates happen on the 64 bit min/max bounds and given we coerced
> > the register, the sign bits of the bounds are cleared as well, meaning, we
> > need to force the simulation into s32 space for 32 bit alu mode.
> >
> > Verification after the fix below. We're first analyzing the fall-through branch
> > on 32 bit signed >= test eventually leading to rejection of the program in this
> > specific case:
> >
> >    0: R1=ctx(id=0,off=0,imm=0) R10=fp0
> >    0: (b7) r2 = 808464432
> >    1: R1=ctx(id=0,off=0,imm=0) R2_w=invP808464432 R10=fp0
> >    1: (85) call bpf_get_socket_cookie#46
> >    2: R0_w=invP(id=0) R10=fp0
> >    2: (bf) r6 = r0
> >    3: R0_w=invP(id=0) R6_w=invP(id=0) R10=fp0
> >    3: (57) r6 &= 808464432
> >    4: R0_w=invP(id=0) R6_w=invP(id=0,umax_value=808464432,var_off=(0x0; 0x30303030)) R10=fp0
> >    4: (14) w6 -= 810299440
> >    5: R0_w=invP(id=0) R6_w=invP(id=0,umax_value=4294967295,var_off=(0xcf800000; 0x3077fff0)) R10=fp0
> >    5: (c4) w6 s>>= 1
> >    6: R0_w=invP(id=0) R6_w=invP(id=0,umin_value=3888119808,umax_value=4294705144,var_off=(0xe7c00000; 0x183bfff8)) R10=fp0
> >                                                (0x67c00000)          (0xfffbfff8)
> >    6: (76) if w6 s>= 0x30303030 goto pc+216
> >    7: R0_w=invP(id=0) R6_w=invP(id=0,umin_value=3888119808,umax_value=4294705144,var_off=(0xe7c00000; 0x183bfff8)) R10=fp0
> >    7: (30) r0 = *(u8 *)skb[808464432]
> >    BPF_LD_[ABS|IND] uses reserved fields
> >    processed 8 insns (limit 1000000) [...]
> >
> > Fixes: 9cbe1f5a32dc ("bpf/verifier: improve register value range tracking with ARSH")
> > Reported-by: Anatoly Trosinenko <anatoly.trosinenko@...il.com>
> > Signed-off-by: Daniel Borkmann <daniel@...earbox.net>
>
> Acked-by: Yonghong Song <yhs@...com>

Applied. Thanks

Powered by blists - more mailing lists