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

[Casey Schaufler]

On 8/16/2022 8:01 AM, Paul Moore 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.

I am trying to track down an intermittent UDP peersec failure in the
Smack stack as well. It could be related. There are no changes in the
Smack code that would account for it.