Re: BUG: unable to handle kernel paging request in __build_skb

[Willem de Bruijn]

On Sun, Apr 11, 2021 at 9:31 PM Hao Sun <sunhao.th@xxxxxxxxx> wrote:
>
> Hi
>
> When using Healer(https://github.com/SunHao-0/healer/tree/dev) to fuzz
> the Linux kernel, I found the following bug report, but I'm not sure
> about this.
> Sorry, I do not have a reproducing program for this bug.
> I hope that the stack trace information in the crash log can help you
> locate the problem.
>
> Here is the details:
> commit:   4ebaab5fb428374552175aa39832abf5cedb916a
> version:   linux 5.12
> git tree:    kmsan
>
> ==============================================
> RAX: ffffffffffffffda RBX: 000000000059c080 RCX: 000000000047338d
> RDX: 0000000000000010 RSI: 0000000020002400 RDI: 0000000000000003
> RBP: 00007fb6512c2c90 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000005
> R13: 00007fffbb36285f R14: 00007fffbb362a00 R15: 00007fb6512c2dc0
> BUG: unable to handle page fault for address: ffffa73d01c96a40
> #PF: supervisor write access in kernel mode
> #PF: error_code(0x0002) - not-present page
> PGD 1810067 P4D 1810067 PUD 1915067 PMD 4b84067 PTE 0
> Oops: 0002 [#1] SMP
> CPU: 0 PID: 6273 Comm: syz-executor Not tainted 5.12.0-rc6+ #1
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.13.0-1ubuntu1.1 04/01/2014
> RIP: 0010:memset_erms+0x9/0x10 arch/x86/lib/memset_64.S:64
> Code: c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6
> f3 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 <f3> aa
> 4c 89 c8 c3 90 49 89 fa 40 0f b6 ce 48 b8 01 01 01 01 01 01
> RSP: 0018:ffff9f3d01c9b930 EFLAGS: 00010082
> RAX: ffffa73d01c96a00 RBX: 0000000000000020 RCX: 0000000000000020
> RDX: 0000000000000020 RSI: 0000000000000000 RDI: ffffa73d01c96a40
> RBP: ffff9f3d01c9b960 R08: ffffc2390000000f R09: ffffa73d01c96a40
> R10: 000000007dee4e6b R11: ffffffffb2000782 R12: 0000000000000000
> R13: 0000000000000020 R14: 0000000000000000 R15: ffff9f3d01c96a40
> FS:  00007fb6512c3700(0000) GS:ffff97407fa00000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: ffffa73d01c96a40 CR3: 0000000030087005 CR4: 0000000000770ef0
> PKRU: 55555554
> Call Trace:
>  kmsan_internal_unpoison_shadow+0x1d/0x70 mm/kmsan/kmsan.c:110
>  __msan_memset+0x64/0xb0 mm/kmsan/kmsan_instr.c:130
>  __build_skb_around net/core/skbuff.c:209 [inline]
>  __build_skb+0x34b/0x520 net/core/skbuff.c:243
>  netlink_alloc_large_skb net/netlink/af_netlink.c:1193 [inline]
>  netlink_sendmsg+0xdc1/0x14d0 net/netlink/af_netlink.c:1902
>  sock_sendmsg_nosec net/socket.c:654 [inline]
>  sock_sendmsg net/socket.c:674 [inline]

I don't have an idea what might be up, but some context:

This happens in __build_skb_around at

        memset(shinfo, 0, offsetof(struct skb_shared_info, dataref));

on vmalloc'd memory in netloc_alloc_large_skb:

        data = vmalloc(size);
        if (data == NULL)
                return NULL;

        skb = __build_skb(data, size);