Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3057078pxj; Mon, 7 Jun 2021 00:43:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJymHgBjomLVYa3csrdjF4dQJ9Dd/YP3Ey6tK/Nv0J3hqE7y7ob67Tuc9lghr5YHvfAH9+sn X-Received: by 2002:aa7:da94:: with SMTP id q20mr18706817eds.310.1623051807603; Mon, 07 Jun 2021 00:43:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623051807; cv=none; d=google.com; s=arc-20160816; b=WM8/kynum8bPoQ9MMT6zFM1SN0Lts+E7jqhCDTAzlcKGECkzFh1zwH8YsTC0dAVnfD 7s3eTEZjbTebp6xZwB7JfDmeUyY46D/IXL3fbumALRxQzxv6qZBiuFkz31HVquG3nKAy YlcWZXKGKLJvjfl72umSfwGpB8ASq959xasyNSAY6Ms7q2n2N2vwgLpWI/XulrJFblw9 vvVXgO/tQ4N5X4urWYML2uT9PPUawws1iIx7n5VjIwvlW7MBhiBG5wu16i6waVq5aboQ JrlnzcK2jEtme43cyKwzE8oKN2aSCAmqmVbLZFvNqqsyesHCcEDeFza7ysASymjL5ZER N2jQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=FkDnZkLm7S26Fub+7GJQrbQgH8zlz9fkqHVVt8EUVII=; b=eHBdandpnUljosLGBZeRLPGCZu6bwHHFi6jzyQ47vrXOG0ke1jsGOco2fKahSTAsTE 79x/69Q9uRRFR2V7hax2tSwWyWfp3EgargT44SLh7JX5MpfL+01tt/HYD+UirTZNxyhW ZwxShiRKE4RNr4waCfbFgpOSOsAAwGGnH9d/Y2Mw/OdMK8N03PK2/Z8MkHNYRtBLrPZ4 vdnN750Sk7LYgY2sj49erC4D6mjs6XG5mosAcE0Ngq6R3sLPOw5vx57rJvO1bxL6xlxf 1F7yLFwVQfCa2CDLpdeiVqt8JfQOv4H1z222sIsXl6qowkpQe3Qtr5NZKVtx/zXqfkSK wEYw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=nHm4WK6c; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m9si11560241eds.467.2021.06.07.00.43.05; Mon, 07 Jun 2021 00:43:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=nHm4WK6c; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230173AbhFGHlr (ORCPT + 99 others); Mon, 7 Jun 2021 03:41:47 -0400 Received: from mail-qt1-f172.google.com ([209.85.160.172]:35347 "EHLO mail-qt1-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229545AbhFGHlq (ORCPT ); Mon, 7 Jun 2021 03:41:46 -0400 Received: by mail-qt1-f172.google.com with SMTP id k19so11956423qta.2 for ; Mon, 07 Jun 2021 00:39:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FkDnZkLm7S26Fub+7GJQrbQgH8zlz9fkqHVVt8EUVII=; b=nHm4WK6cYXy60WGLih3X49PfQoCmkrbdxEffYKfbL3/RwZaUJn+ZpFlw1f4qhBKOsh ahRqwNfz/pELzJOgvhEH7fSmrENCdPGqiDPPnxASXGD5q9sd6Dk5WUdbdBbPUArWSpgz YhjtWV0vG8EhX7zQlQ+lNbW/aFKCucpeFKWsmDvBb4gvT3urI0A7KLePEk+N9605Vxec pkm2nZH26PbCFEe3Rt8MWK2GYZWEhX1zJkTawVJymWS9/t+exzEZtixnPBaQ3CKp7qxO KJPc74KVXSeqk4iHCZH7tGPVflFVx/UFdpy6RZ1xAkh+rjGRzUNDiP+yZ5nLQUld/tUh Nh2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FkDnZkLm7S26Fub+7GJQrbQgH8zlz9fkqHVVt8EUVII=; b=WWVXShGi89owH1f857HBZlcroSld9mAvOs6Rb8gSlxHQPnN2/O0BqI8nBrbW0ZvDeD FDjOvvMhVANurkbqsDGpVbaKzrkWV4HmfIXXhWKq69jCsa6c0LrmQqVDvn450zQvNRP/ 4soXJJ1lHFCZv9/MuLkBeqfaZV62OF/yqDynadpPeaIJM9m+2B8L3+DhKy0zvrYwRIBE BSPrrBPLo3EJVIUoj39Fa1fiL67jQ5PuNIgKc1SE8DEMH2H4r1d1AdVDrH+o4Xz9rBj6 YRmEW3eKXDV24gYkKjY8fsP5mzPUPcdihgEAUiqOAHtrfF5xBHPIYwL9QfuDQ/Hs9Gat U3eA== X-Gm-Message-State: AOAM531wQMBYKn7mxlm1qeE4I3F7JID/5HEsfAcAw7HHllqp2O7FCzcs jhWlo7CRDyEPVHGyMTFxeIXr74JXsm12E0iVMkuX0g== X-Received: by 2002:ac8:7c4e:: with SMTP id o14mr14825948qtv.290.1623051534847; Mon, 07 Jun 2021 00:38:54 -0700 (PDT) MIME-Version: 1.0 References: <000000000000c2987605be907e41@google.com> <20210602212726.7-1-fuzzybritches0@gmail.com> <87609-531187-curtm@phaethon> <6a392b66-6f26-4532-d25f-6b09770ce366@fb.com> In-Reply-To: From: Dmitry Vyukov Date: Mon, 7 Jun 2021 09:38:43 +0200 Message-ID: Subject: Re: [PATCH v4] bpf: core: fix shift-out-of-bounds in ___bpf_prog_run To: Alexei Starovoitov Cc: Yonghong Song , Kurt Manucredo , syzbot+bed360704c521841c85d@syzkaller.appspotmail.com, Andrii Nakryiko , Alexei Starovoitov , bpf , Daniel Borkmann , "David S. Miller" , Jesper Dangaard Brouer , John Fastabend , Martin KaFai Lau , KP Singh , Jakub Kicinski , LKML , Network Development , Song Liu , syzkaller-bugs , nathan@kernel.org, Nick Desaulniers , Clang-Built-Linux ML , linux-kernel-mentees@lists.linuxfoundation.org, Shuah Khan , Greg Kroah-Hartman , Kernel Hardening , kasan-dev Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jun 5, 2021 at 9:10 PM Alexei Starovoitov wrote: > On Sat, Jun 5, 2021 at 10:55 AM Yonghong Song wrote: > > On 6/5/21 8:01 AM, Kurt Manucredo wrote: > > > Syzbot detects a shift-out-of-bounds in ___bpf_prog_run() > > > kernel/bpf/core.c:1414:2. > > > > This is not enough. We need more information on why this happens > > so we can judge whether the patch indeed fixed the issue. > > > > > > > > I propose: In adjust_scalar_min_max_vals() move boundary check up to avoid > > > missing them and return with error when detected. > > > > > > Reported-and-tested-by: syzbot+bed360704c521841c85d@syzkaller.appspotmail.com > > > Signed-off-by: Kurt Manucredo > > > --- > > > > > > https://syzkaller.appspot.com/bug?id=edb51be4c9a320186328893287bb30d5eed09231 > > > > > > Changelog: > > > ---------- > > > v4 - Fix shift-out-of-bounds in adjust_scalar_min_max_vals. > > > Fix commit message. > > > v3 - Make it clearer what the fix is for. > > > v2 - Fix shift-out-of-bounds in ___bpf_prog_run() by adding boundary > > > check in check_alu_op() in verifier.c. > > > v1 - Fix shift-out-of-bounds in ___bpf_prog_run() by adding boundary > > > check in ___bpf_prog_run(). > > > > > > thanks > > > > > > kind regards > > > > > > Kurt > > > > > > kernel/bpf/verifier.c | 30 +++++++++--------------------- > > > 1 file changed, 9 insertions(+), 21 deletions(-) > > > > > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c > > > index 94ba5163d4c5..ed0eecf20de5 100644 > > > --- a/kernel/bpf/verifier.c > > > +++ b/kernel/bpf/verifier.c > > > @@ -7510,6 +7510,15 @@ static int adjust_scalar_min_max_vals(struct bpf_verifier_env *env, > > > u32_min_val = src_reg.u32_min_value; > > > u32_max_val = src_reg.u32_max_value; > > > > > > + if ((opcode == BPF_LSH || opcode == BPF_RSH || opcode == BPF_ARSH) && > > > + umax_val >= insn_bitness) { > > > + /* Shifts greater than 31 or 63 are undefined. > > > + * This includes shifts by a negative number. > > > + */ > > > + verbose(env, "invalid shift %lld\n", umax_val); > > > + return -EINVAL; > > > + } > > > > I think your fix is good. I would like to move after > > I suspect such change will break valid programs that do shift by register. > > > the following code though: > > > > if (!src_known && > > opcode != BPF_ADD && opcode != BPF_SUB && opcode != BPF_AND) { > > __mark_reg_unknown(env, dst_reg); > > return 0; > > } > > > > > + > > > if (alu32) { > > > src_known = tnum_subreg_is_const(src_reg.var_off); > > > if ((src_known && > > > @@ -7592,39 +7601,18 @@ static int adjust_scalar_min_max_vals(struct bpf_verifier_env *env, > > > scalar_min_max_xor(dst_reg, &src_reg); > > > break; > > > case BPF_LSH: > > > - if (umax_val >= insn_bitness) { > > > - /* Shifts greater than 31 or 63 are undefined. > > > - * This includes shifts by a negative number. > > > - */ > > > - mark_reg_unknown(env, regs, insn->dst_reg); > > > - break; > > > - } > > > > I think this is what happens. For the above case, we simply > > marks the dst reg as unknown and didn't fail verification. > > So later on at runtime, the shift optimization will have wrong > > shift value (> 31/64). Please correct me if this is not right > > analysis. As I mentioned in the early please write detailed > > analysis in commit log. > > The large shift is not wrong. It's just undefined. > syzbot has to ignore such cases. Hi Alexei, The report is produced by KUBSAN. I thought there was an agreement on cleaning up KUBSAN reports from the kernel (the subset enabled on syzbot at least). What exactly cases should KUBSAN ignore? +linux-hardening/kasan-dev for KUBSAN false positive