Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <00000000000037341d05fc460fa6@google.com> <CAF=yD-JpUc3SLtd7MtULmKOcERf6EJZ0rPc7WmJB2nUNUQRBjA@mail.gmail.com>
 <CAF=yD-+MxyoD1Mbekf93-XhAA2urAf5audD8HefmF8bfsu51iQ@mail.gmail.com>
In-Reply-To: <CAF=yD-+MxyoD1Mbekf93-XhAA2urAf5audD8HefmF8bfsu51iQ@mail.gmail.com>
From:   Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date:   Sat, 27 May 2023 16:32:31 -0400
Message-ID: <CAF=yD-Ln94Nim0GkpLhZ7p7qQFUDE4Z-adrjRMRSh2y3iBmb+w@mail.gmail.com>
Subject: Re: [syzbot] [net?] KASAN: invalid-access Read in __packet_get_status
To:     syzbot <syzbot+64b0f633159fde08e1f1@syzkaller.appspotmail.com>
Cc:     bpf@vger.kernel.org, davem@davemloft.net, edumazet@google.com,
        kuba@kernel.org, linux-kernel@vger.kernel.org,
        netdev@vger.kernel.org, pabeni@redhat.com,
        syzkaller-bugs@googlegroups.com,
        linux-arm-kernel@lists.infradead.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Mon, May 22, 2023 at 12:19=E2=80=AFPM Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>
> On Mon, May 22, 2023 at 10:52=E2=80=AFAM Willem de Bruijn
> <willemdebruijn.kernel@gmail.com> wrote:
> >
> > On Mon, May 22, 2023 at 6:51=E2=80=AFAM syzbot
> > <syzbot+64b0f633159fde08e1f1@syzkaller.appspotmail.com> wrote:
> > >
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit:    2d1bcbc6cd70 Merge tag 'probes-fixes-v6.4-rc1' of git=
://gi..
> > > git tree:       upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=3D154b8fa12=
80000
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=3D51dd28037=
b2a55f
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=3D64b0f633159=
fde08e1f1
> > > compiler:       aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 202101=
10, GNU ld (GNU Binutils for Debian) 2.35.2
> > > userspace arch: arm64
> > > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=3D12b6382=
e280000
> > > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=3D17fd0aee2=
80000
> > >
> > > Downloadable assets:
> > > disk image (non-bootable): https://storage.googleapis.com/syzbot-asse=
ts/384ffdcca292/non_bootable_disk-2d1bcbc6.raw.xz
> > > vmlinux: https://storage.googleapis.com/syzbot-assets/d2e21a43e11e/vm=
linux-2d1bcbc6.xz
> > > kernel image: https://storage.googleapis.com/syzbot-assets/49e0b029f9=
af/Image-2d1bcbc6.gz.xz
> > >
> > > IMPORTANT: if you fix the issue, please add the following tag to the =
commit:
> > > Reported-by: syzbot+64b0f633159fde08e1f1@syzkaller.appspotmail.com
> > >
> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > BUG: KASAN: invalid-access in __packet_get_status+0x70/0xe0 net/packe=
t/af_packet.c:438
> >
> > The offending line is the last one in
> >
> > "
> > static int __packet_get_status(const struct packet_sock *po, void *fram=
e)
> > {
> >         union tpacket_uhdr h;
> >
> >         smp_rmb();
> >
> >         h.raw =3D frame;
> >         switch (po->tp_version) {
> >         case TPACKET_V1:
> >                 flush_dcache_page(pgv_to_page(&h.h1->tp_status));
> >                 return h.h1->tp_status;
> >         case TPACKET_V2:
> >                 flush_dcache_page(pgv_to_page(&h.h2->tp_status));
> > "
> >
> > The reproducer is very small:
> >
> > "
> > // socket(PF_PACKET, SOCK_DGRAM, htons(ETH_P_ALL);
> > r0 =3D socket$packet(0x11, 0x2, 0x300)
> >
> > // setsockopt PACKET_RX_RING with same block and frame sizes and counts
> > setsockopt$packet_rx_ring(r0, 0x107, 0x5,
> > &(0x7f0000000040)=3D@req3=3D{0x8000, 0x200, 0x80, 0x20000}, 0x1c)
> >
> > // excessive length, too many bits in prot, MAP_SHARED | MAP_ANONYMOUS
> > mmap(&(0x7f0000568000/0x2000)=3Dnil, 0x1000000, 0x20567fff, 0x11, r0, 0=
x0)
> > "
> >
> > What is odd here is that the program never sets packet version
> > explicitly, and the default is TPACKET_V1.
>
> The test is marked as repeat.
>
> One possibility is that there is a race between packet arrival calling
> flush_dcache_page and user mmap setup/teardown. That would exhibit as
> flakiness.
>
> ARM flush_dcache_page is quite outside my networking comfort zone.

The accessed memory is using ARM MTE tags. It appears that the memory
is accessed with the wrong tag:

 do_tag_check_fault+0x78/0x8c arch/arm64/mm/fault.c:791
 do_mem_abort+0x44/0x94 arch/arm64/mm/fault.c:867
 el1_abort+0x40/0x60 arch/arm64/kernel/entry-common.c:367
 el1h_64_sync_handler+0xd8/0xe4 arch/arm64/kernel/entry-common.c:427
 el1h_64_sync+0x64/0x68 arch/arm64/kernel/entry.S:586
 __packet_get_status+0x70/0xe0 net/packet/af_packet.c:438