lkml.org 
[lkml]   [2019]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: BUG: unable to handle kernel NULL pointer dereference in mem_serial_out
On Fri, Dec 13, 2019 at 11:00:35AM +0100, Dmitry Vyukov wrote:
> On Fri, Dec 13, 2019 at 10:34 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Fri, Dec 13, 2019 at 10:02:33AM +0100, Dmitry Vyukov wrote:
> > > On Thu, Dec 12, 2019 at 11:57 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Fri, Dec 06, 2019 at 10:25:08PM -0800, syzbot wrote:
> > > > > Hello,
> > > > >
> > > > > syzbot found the following crash on:
> > > > >
> > > > > HEAD commit: 7ada90eb Merge tag 'drm-next-2019-12-06' of git://anongit...
> > > > > git tree: upstream
> > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=123ec282e00000
> > > > > kernel config: https://syzkaller.appspot.com/x/.config?x=f07a23020fd7d21a
> > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=f4f1e871965064ae689e
> > > > > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17ab090ee00000
> > > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17f127f2e00000
> > > > >
> > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > > > Reported-by: syzbot+f4f1e871965064ae689e@syzkaller.appspotmail.com
> > > > >
> > > > > BUG: kernel NULL pointer dereference, address: 0000000000000002
> > > > > #PF: supervisor write access in kernel mode
> > > > > #PF: error_code(0x0002) - not-present page
> > > > > PGD 9764a067 P4D 9764a067 PUD 9f995067 PMD 0
> > > > > Oops: 0002 [#1] PREEMPT SMP KASAN
> > > > > CPU: 0 PID: 9687 Comm: syz-executor433 Not tainted 5.4.0-syzkaller #0
> > > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > > > > Google 01/01/2011
> > > > > RIP: 0010:writeb arch/x86/include/asm/io.h:65 [inline]
> > > > > RIP: 0010:mem_serial_out+0x70/0x90 drivers/tty/serial/8250/8250_port.c:408
> > > > > Code: e9 00 00 00 49 8d 7c 24 40 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48
> > > > > c1 ea 03 d3 e3 80 3c 02 00 75 19 48 63 db 49 03 5c 24 40 <44> 88 2b 5b 41 5c
> > > > > 41 5d 5d c3 e8 81 ed cf fd eb c0 e8 da ed cf fd
> > > > > RSP: 0018:ffffc90001de78e8 EFLAGS: 00010202
> > > > > RAX: dffffc0000000000 RBX: 0000000000000002 RCX: 0000000000000000
> > > > > RDX: 1ffffffff181f40e RSI: ffffffff83e28776 RDI: ffffffff8c0fa070
> > > > > RBP: ffffc90001de7900 R08: ffff8880919dc340 R09: ffffed10431ee1c6
> > > > > R10: ffffed10431ee1c5 R11: ffff888218f70e2b R12: ffffffff8c0fa030
> > > > > R13: 0000000000000001 R14: ffffc90001de7a40 R15: ffffffff8c0fa188
> > > > > FS: 0000000001060880(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
> > > > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > > > > CR2: 0000000000000002 CR3: 000000009e6b8000 CR4: 00000000001406f0
> > > > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > > > > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > > > > Call Trace:
> > > > > serial_out drivers/tty/serial/8250/8250.h:118 [inline]
> > > > > serial8250_clear_fifos.part.0+0x3a/0xb0
> > > > > drivers/tty/serial/8250/8250_port.c:557
> > > > > serial8250_clear_fifos drivers/tty/serial/8250/8250_port.c:556 [inline]
> > > > > serial8250_do_startup+0x426/0x1cf0 drivers/tty/serial/8250/8250_port.c:2121
> > > > > serial8250_startup+0x62/0x80 drivers/tty/serial/8250/8250_port.c:2329
> > > > > uart_port_startup drivers/tty/serial/serial_core.c:219 [inline]
> > > > > uart_startup drivers/tty/serial/serial_core.c:258 [inline]
> > > > > uart_startup+0x452/0x980 drivers/tty/serial/serial_core.c:249
> > > > > uart_set_info drivers/tty/serial/serial_core.c:998 [inline]
> > > > > uart_set_info_user+0x13b4/0x1cf0 drivers/tty/serial/serial_core.c:1023
> > > > > tty_tiocsserial drivers/tty/tty_io.c:2506 [inline]
> > > > > tty_ioctl+0xf60/0x14f0 drivers/tty/tty_io.c:2648
> > > > > vfs_ioctl fs/ioctl.c:47 [inline]
> > > > > file_ioctl fs/ioctl.c:545 [inline]
> > > > > do_vfs_ioctl+0x977/0x14e0 fs/ioctl.c:732
> > > > > ksys_ioctl+0xab/0xd0 fs/ioctl.c:749
> > > > > __do_sys_ioctl fs/ioctl.c:756 [inline]
> > > > > __se_sys_ioctl fs/ioctl.c:754 [inline]
> > > > > __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:754
> > > > > do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
> > > > > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > > > > RIP: 0033:0x440219
> > > > > Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 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
> > > > > 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
> > > > > RSP: 002b:00007ffced648c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> > > > > RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000440219
> > > > > RDX: 0000000020000240 RSI: 000000000000541f RDI: 0000000000000003
> > > > > RBP: 00000000006ca018 R08: 0000000000000000 R09: 00000000004002c8
> > > > > R10: 0000000000401b30 R11: 0000000000000246 R12: 0000000000401aa0
> > > > > R13: 0000000000401b30 R14: 0000000000000000 R15: 0000000000000000
> > > > > Modules linked in:
> > > > > CR2: 0000000000000002
> > > > > ---[ end trace eaa11ffe82f3a763 ]---
> > > > > RIP: 0010:writeb arch/x86/include/asm/io.h:65 [inline]
> > > > > RIP: 0010:mem_serial_out+0x70/0x90 drivers/tty/serial/8250/8250_port.c:408
> > > > > Code: e9 00 00 00 49 8d 7c 24 40 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48
> > > > > c1 ea 03 d3 e3 80 3c 02 00 75 19 48 63 db 49 03 5c 24 40 <44> 88 2b 5b 41 5c
> > > > > 41 5d 5d c3 e8 81 ed cf fd eb c0 e8 da ed cf fd
> > > > > RSP: 0018:ffffc90001de78e8 EFLAGS: 00010202
> > > > > RAX: dffffc0000000000 RBX: 0000000000000002 RCX: 0000000000000000
> > > > > RDX: 1ffffffff181f40e RSI: ffffffff83e28776 RDI: ffffffff8c0fa070
> > > > > RBP: ffffc90001de7900 R08: ffff8880919dc340 R09: ffffed10431ee1c6
> > > > > R10: ffffed10431ee1c5 R11: ffff888218f70e2b R12: ffffffff8c0fa030
> > > > > R13: 0000000000000001 R14: ffffc90001de7a40 R15: ffffffff8c0fa188
> > > > > FS: 0000000001060880(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
> > > > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > > > > CR2: 0000000000000002 CR3: 000000009e6b8000 CR4: 00000000001406f0
> > > > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > > > > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > > > >
> > > >
> > > > You set up a dubious memory base for your uart and then get upset when
> > > > you write to that location.
> > > >
> > > > I don't know what to really do about this, this is a root-only operation
> > > > and you are expected to know what you are doing when you attempt this.
> > >
> > > Hi Greg,
> > >
> > > Thanks for looking into this!
> > > Should we restrict the fuzzer from accessing /dev/ttyS* entirely?
> >
> > No, not at all.
> >
> > > Or only restrict TIOCSSERIAL on them? Something else?
> >
> > Try running not as root. if you have CAP_SYS_ADMIN you can do a lot of
> > pretty bad things with tty ports, as you see here. There's a reason the
> > LOCKDOWN_TIOCSSERIAL "security lockdown" check was added :)
> >
> > The TIOCSSERIAL ioctl is a nice one for a lot of things that are able to
> > be done as a normal user (baud rate changes, etc.), but there are also
> > things like setting io port memory locations that can cause random
> > hardware accesses and kernel crashes, as you instantly found out here :)
> >
> > So restrict the fuzzer to only run as a "normal" user of the serial
> > port, and if you find problems there, I'll be glad to look at them.
>
> Easier said than done. "normal user of the serial port" is not really
> a thing in Linux, right? You either have CAP_SYS_ADMIN or not, that's
> not per-device...

Not true, there's lots of users of serial port devices that do not have
CAP_SYS_ADMIN set. That's why we have groups :)

You can change the baud rate of your usb-serial device without root
permissions, right? That's a "normal" user right there.

> As far as I remember +Tetsuo proposed a config along the lines of
> "restrict only things that legitimately cause damage under a fuzzer
> workload", e.g. freezing filesystems, disabling console output, etc.
> This may be another candidate. But I can't find where that proposal is
> now.
>
> A simpler option that I see is as follows. syzkaller has several
> sandboxing modes, one of them is "namespace" which uses a user ns, in
> that more fuzzer is still uid=0 in the init namespace, so has access
> to all /dev nodes, but it does not have CAP_SYS_ADMIN in the init
> namespace. We could enable /dev/ttyS* only on instance that use
> sandbox=namesace, and disable on the rest. Does it make sense?

Maybe, I don't know. Why do you have to run the fuzzer with uid=0 in
the first place?

thanks,

greg k-h

\
 
 \ /
  Last update: 2019-12-13 11:10    [W:0.085 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site