general protection fault in xsk_recvmsg

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: df542285 Merge branch 'xdp-preferred-busy-polling'
git tree: bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=11426809500000
kernel config: https://syzkaller.appspot.com/x/.config?x=6774dc081604c527
dashboard link: https://syzkaller.appspot.com/bug?extid=b974d32294d1dffbea36
compiler: gcc (GCC) 10.1.0-syz 20200507
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1648b0e5500000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=125af4ad500000

The issue was bisected to:

commit dcd479e10a0510522a5d88b29b8f79ea3467d501
Author: Johannes Berg <johann...@intel.com>
Date: Fri Oct 9 12:17:11 2020 +0000

mac80211: always wind down STA state

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=12356d1d500000
final oops: https://syzkaller.appspot.com/x/report.txt?x=11356d1d500000
console output: https://syzkaller.appspot.com/x/log.txt?x=16356d1d500000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+b974d3...@syzkaller.appspotmail.com
Fixes: dcd479e10a05 ("mac80211: always wind down STA state")

general protection fault, probably for non-canonical address 0xdffffc0000000045: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000228-0x000000000000022f]
CPU: 1 PID: 8481 Comm: syz-executor119 Not tainted 5.10.0-rc3-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:xsk_recvmsg+0x79/0x5e0 net/xdp/xsk.c:563
Code: 03 80 3c 02 00 0f 85 00 05 00 00 48 8b 9d c8 04 00 00 48 b8 00 00 00 00 00 fc ff df 48 8d bb 28 02 00 00 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 9c 04 00 00 8b 9b 28 02 00 00
RSP: 0018:ffffc9000165fae0 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000040000000
RDX: 0000000000000045 RSI: ffffffff88a6a995 RDI: 0000000000000228
RBP: ffff88801a140000 R08: 0000000040000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000040000000
R13: 0000000040000000 R14: ffffc9000165fe98 R15: 0000000000000000
FS: 00000000007fd880(0000) GS:ffff8880b9f00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020004880 CR3: 000000001f1bd000 CR4: 00000000001506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
sock_recvmsg_nosec net/socket.c:885 [inline]
sock_recvmsg net/socket.c:903 [inline]
sock_recvmsg net/socket.c:899 [inline]
____sys_recvmsg+0x2c4/0x600 net/socket.c:2576
___sys_recvmsg+0x127/0x200 net/socket.c:2618
__sys_recvmsg+0xe2/0x1a0 net/socket.c:2654
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x440269
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffdbb92b6c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002f
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000440269
RDX: 0000000040000000 RSI: 0000000020004880 RDI: 0000000000000003
RBP: 00000000006ca018 R08: 0000000000000000 R09: 00000000004002c8
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000401a70
R13: 0000000000401b00 R14: 0000000000000000 R15: 0000000000000000
Modules linked in:
---[ end trace 184efc29c05fd9c5 ]---
RIP: 0010:xsk_recvmsg+0x79/0x5e0 net/xdp/xsk.c:563
Code: 03 80 3c 02 00 0f 85 00 05 00 00 48 8b 9d c8 04 00 00 48 b8 00 00 00 00 00 fc ff df 48 8d bb 28 02 00 00 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 9c 04 00 00 8b 9b 28 02 00 00
RSP: 0018:ffffc9000165fae0 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000040000000
RDX: 0000000000000045 RSI: ffffffff88a6a995 RDI: 0000000000000228
RBP: ffff88801a140000 R08: 0000000040000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000040000000
R13: 0000000040000000 R14: ffffc9000165fe98 R15: 0000000000000000
FS: 00000000007fd880(0000) GS:ffff8880b9e00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f66a803d058 CR3: 000000001f1bd000 CR4: 00000000001506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches

[Björn Töpel]

#syz fix: xsk: Validate socket state in xsk_recvmsg, prior touching
socket members

[Dmitry Vyukov]

On Fri, Jan 15, 2021 at 1:50 PM Björn Töpel <bjorn...@intel.com> wrote:
>
> #syz fix: xsk: Validate socket state in xsk_recvmsg, prior touching
> socket members

-most

This got unrecoverably corrupted with line wraps by email client.
As my client does the same, there is a special hack that allows to
send a least a little bit longer titles w/o line wrapping: syz fix
alone on one line and whole title on the next line: