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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

-- 
paul-moore.com



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux