Re: [syzbot] KASAN: use-after-free Read in sock_has_perm

[Dmitry Vyukov]

On Tue, 16 Aug 2022 at 17:02, Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
>
> On Tue, Aug 16, 2022 at 4:00 AM syzbot
> <syzbot+2f2c6bea25b08dc06f86@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:    200e340f2196 Merge tag 'pull-work.dcache' of git://git.ker..
> > git tree:       upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=16021dfd080000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=f2886ebe3c7b3459
> > dashboard link: https://syzkaller.appspot.com/bug?extid=2f2c6bea25b08dc06f86
> > compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
> >
> > Unfortunately, I don't have any reproducer for this issue yet.
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+2f2c6bea25b08dc06f86@xxxxxxxxxxxxxxxxxxxxxxxxx
> >
> > ==================================================================
> > BUG: KASAN: use-after-free in sock_has_perm+0x258/0x280 security/selinux/hooks.c:4532
> > Read of size 8 at addr ffff88807630e480 by task syz-executor.0/8123
> >
> > CPU: 1 PID: 8123 Comm: syz-executor.0 Not tainted 5.19.0-syzkaller-02972-g200e340f2196 #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022
> > Call Trace:
> >  <TASK>
> >  __dump_stack lib/dump_stack.c:88 [inline]
> >  dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
> >  print_address_description.constprop.0.cold+0xeb/0x467 mm/kasan/report.c:313
> >  print_report mm/kasan/report.c:429 [inline]
> >  kasan_report.cold+0xf4/0x1c6 mm/kasan/report.c:491
> >  sock_has_perm+0x258/0x280 security/selinux/hooks.c:4532
> >  selinux_socket_setsockopt+0x3e/0x80 security/selinux/hooks.c:4913
> >  security_socket_setsockopt+0x50/0xb0 security/security.c:2249
> >  __sys_setsockopt+0x107/0x6a0 net/socket.c:2233
> >  __do_sys_setsockopt net/socket.c:2266 [inline]
> >  __se_sys_setsockopt net/socket.c:2263 [inline]
> >  __x64_sys_setsockopt+0xba/0x150 net/socket.c:2263
> >  do_syscall_x64 arch/x86/entry/common.c:50 [inline]
> >  do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
> >  entry_SYSCALL_64_after_hwframe+0x63/0xcd
> > RIP: 0033:0x7f96c7289279
> > Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
> > RSP: 002b:00007f96c842f168 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
> > RAX: ffffffffffffffda RBX: 00007f96c739c050 RCX: 00007f96c7289279
> > RDX: 0000000000000007 RSI: 0000000000000103 RDI: 0000000000000004
> > RBP: 00007f96c72e3189 R08: 0000000000000004 R09: 0000000000000000
> > R10: 0000000020000000 R11: 0000000000000246 R12: 0000000000000000
> > R13: 00007ffe7030593f R14: 00007f96c842f300 R15: 0000000000022000
> >  </TASK>
>
> SELinux hasn't changed anything in this area for a while, and looking
> over everything again just now it still looks sane to me.  I suspect
> there is something else going on with respect to socket lifetimes and
> SELinux just happens to be the one that catches the use-after-free
> first.

My completely unfounded guess would be that net/netrom/af_netrom.c
does incorrect socket lifetime management.

Though, that wouldn't explain what Casey mentioned re UDP. But it can
well be 2 separate issues.