lkml.org 
[lkml]   [2022]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [syzbot] KASAN: use-after-free Read in sock_has_perm
On Tue, Aug 16, 2022 at 4:00 AM syzbot
<syzbot+2f2c6bea25b08dc06f86@syzkaller.appspotmail.com> 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@syzkaller.appspotmail.com
>
> ==================================================================
> 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

\
 
 \ /
  Last update: 2022-08-16 17:05    [W:0.054 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site