On Mon, May 22, 2023 at 12:19 PM Willem de Bruijn <willemdebruijn.kernel@xxxxxxxxx> wrote: > > On Mon, May 22, 2023 at 10:52 AM Willem de Bruijn > <willemdebruijn.kernel@xxxxxxxxx> wrote: > > > > On Mon, May 22, 2023 at 6:51 AM syzbot > > <syzbot+64b0f633159fde08e1f1@xxxxxxxxxxxxxxxxxxxxxxxxx> 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=154b8fa1280000 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=51dd28037b2a55f > > > dashboard link: https://syzkaller.appspot.com/bug?extid=64b0f633159fde08e1f1 > > > compiler: aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2 > > > userspace arch: arm64 > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12b6382e280000 > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17fd0aee280000 > > > > > > Downloadable assets: > > > disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/384ffdcca292/non_bootable_disk-2d1bcbc6.raw.xz > > > vmlinux: https://storage.googleapis.com/syzbot-assets/d2e21a43e11e/vmlinux-2d1bcbc6.xz > > > kernel image: https://storage.googleapis.com/syzbot-assets/49e0b029f9af/Image-2d1bcbc6.gz.xz > > > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > > Reported-by: syzbot+64b0f633159fde08e1f1@xxxxxxxxxxxxxxxxxxxxxxxxx > > > > > > ================================================================== > > > BUG: KASAN: invalid-access in __packet_get_status+0x70/0xe0 net/packet/af_packet.c:438 > > > > The offending line is the last one in > > > > " > > static int __packet_get_status(const struct packet_sock *po, void *frame) > > { > > union tpacket_uhdr h; > > > > smp_rmb(); > > > > h.raw = 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 = 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)=@req3={0x8000, 0x200, 0x80, 0x20000}, 0x1c) > > > > // excessive length, too many bits in prot, MAP_SHARED | MAP_ANONYMOUS > > mmap(&(0x7f0000568000/0x2000)=nil, 0x1000000, 0x20567fff, 0x11, r0, 0x0) > > " > > > > 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
