Thread (4 messages) 4 messages, 3 authors, 2019-02-04

Re: KASAN: use-after-free Read in selinux_netlbl_socket_setsockopt

From: Paul Moore <paul@paul-moore.com>
Date: 2019-02-01 16:48:38
Also in: linux-hams, lkml, selinux

On Fri, Feb 1, 2019 at 1:26 AM Dmitry Vyukov [off-list ref] wrote:
On Wed, Jan 30, 2019 at 10:30 PM Paul Moore [off-list ref] wrote:
quoted
On Wed, Jan 30, 2019 at 4:01 PM syzbot
[off-list ref] wrote:
quoted
Hello,

syzbot found the following crash on:

HEAD commit:    62967898789d Merge git://git.kernel.org/pub/scm/linux/kern..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=167fdef8c00000
kernel config:  https://syzkaller.appspot.com/x/.config?x=4fceea9e2d99ac20
dashboard link: https://syzkaller.appspot.com/bug?extid=1bfc00ca3aabe5bcd4cb
compiler:       gcc (GCC) 9.0.0 20181231 (experimental)

Unfortunately, I don't have any reproducer for this crash yet.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+1bfc00ca3aabe5bcd4cb@syzkaller.appspotmail.com

8021q: adding VLAN 0 to HW filter on device team0
==================================================================
BUG: KASAN: use-after-free in selinux_netlbl_socket_setsockopt+0x49b/0x510
security/selinux/netlabel.c:525
Read of size 8 at addr ffff8880a63cf078 by task syz-executor3/18477

CPU: 1 PID: 18477 Comm: syz-executor3 Not tainted 5.0.0-rc4+ #51
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
  __dump_stack lib/dump_stack.c:77 [inline]
  dump_stack+0x1db/0x2d0 lib/dump_stack.c:113
  print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
  kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
  __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:135
  selinux_netlbl_socket_setsockopt+0x49b/0x510
security/selinux/netlabel.c:525
At first glance this seems odd.  The line above is simply
dereferencing sock->sk_security (getting the "sksec"), which we also
do higher up selinux_socket_setsockopt() via sock_has_perm().  Unless
somehow the socket is being released/freed in the middle of a
setsockopt() syscall this looks like maybe it's something else?
Hi Paul,

Searching for af_netrom across other syzbot bugs:
https://groups.google.com/forum/#!searchin/syzkaller-bugs/af_netrom%7Csort:date

I see at least:
https://syzkaller.appspot.com/bug?extid=b0b1952f5864b4009b09
https://syzkaller.appspot.com/bug?extid=febf3c50d4262e578b1c
https://syzkaller.appspot.com/bug?extid=defa700d16f1bd1b9a05

Which suggests there are some serious lifetime problems in netrom
sockets. That would probably explain this crash as well.
That definitely looks plausible.  While I'm not one to say it could
*never* be the SELinux/NetLabel code, I can say that the SELinux code
path in question hasn't changed in some time so I would be a little
surprised if it was suddenly broken.
+netrom maintainers, does this explanation look plausible to you?
should we dup this crash onto one of the other netrom bugs? and
perhaps these netrom bugs across themselves too?
-- 
paul moore
www.paul-moore.com
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help