| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAADnVQKeYoPdwTwRQb9smC6Oc9Fcc1m=y-E7UXShOsgjb+Yjpw@mail.gmail.com>
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