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.
