[Linux-kernel-mentees] [SYZBOT REPORT] - BUG: unable to handle kernel NULL
Jiunn Chang
c0d1n61at3 at gmail.com
Fri Jun 28 23:33:33 UTC 2019
On Fri, Jun 28, 2019 at 02:55:46PM -0600, Shuah Khan wrote:
> On 6/28/19 2:31 AM, Jiunn Chang wrote:
> > pointer dereference in hci_uart_set_flow_control
> > Reply-To:
> >
> > Hello,
> >
> > This is an analysis of the following Syzbot report:
> >
> > https://syzkaller.appspot.com/bug?id=1b42faa2848963564a5b1b7f8c837ea7b55ffa50
> >
> > I am able to reproduce this crash on upstream. The .config is for v5.1-rc1, so
> > that is what I tested with. I compiled with gcc 9.1 and used the syz program
> > provided in the report.
> >
> > The RIP register is null, so I had to fallback on the trace to find the site of
> > the error.
> >
> > Trace:
> >
> > [ 74.096479][ T1179] Call Trace:
> > [ 74.096479][ T1179] hci_uart_set_flow_control+0x4fb/0x680
> > [ 74.096479][ T1179] mrvl_setup+0x22/0x110
> > [ 74.096479][ T1179] hci_uart_setup+0x2b0/0x530
> > [ 74.096479][ T1179] hci_dev_do_open+0x78c/0x1780
> > [ 74.096479][ T1179] hci_power_on+0x10d/0x580
> >
> > The trace begins when an hci device being registered and a worker thread call to
> > hci_power_on(). The last call in the trace is to mrvl_setup() calling
> > hci_uart_set_flow_control(). The exact line of the error is:
> >
> > status = tty->driver->ops->tiocmget(tty);
> >
> > The above line is in hci_ldisc.c:327.
> >
> > The syz program is below:
> >
> > #{"procs":1,"sandbox":"","fault_call":-1}
> > r0 = openat$ptmx(0xffffffffffffff9c, &(0x7f0000000000)='/dev/ptmx\x00', 0x0, 0x0)
> > ioctl$TCSETS(r0, 0x40045431, &(0x7f00005befdc))
> > r1 = syz_open_pts(r0, 0x0)
> > ioctl$TIOCSETD(r1, 0x5423, &(0x7f00000000c0)=0xf)
> > ioctl$PIO_FONTRESET(r1, 0x400455c8, 0xb)
> >
> > Analysis:
> >
> > The syz program begins by mapping a ptmx device for a ptm/pts pair. The program
> > then proceeds to set serial port settings and line discipline. If look at the line
> > there the null dereference occurs, it appears that some operations on some drivers
> > may not be needed or supported. I do not know enough about the device core to make
> > that determination. I begin by looking for any patches that deal with
> > hci_uart_set_flow_control().
> >
> > I find this patch: https://patchwork.kernel.org/patch/9985313/
> >
> > It appears that this patch is already in the branch so this is not the fix. I then
> > look for patches that deal with tiocmget(). I find the following patch by Shuah:
> >
> > https://lore.kernel.org/patchwork/patch/1035787/
> >
> > This patch is along the same lines at the the bug I am seeing. The discussion in
> > this patch mentions that setting line discipline on a master pty should not happen.
> > So I grab v2 of that patch here: https://lore.kernel.org/patchwork/patch/1037692/
> >
> > I apply this patch and test again so see if this fixes the bug but got the same
> > trace. I look harder for anything related to tiocmget() and finally find this patch:
> >
> > https://lore.kernel.org/linux-bluetooth/20190212083645.GA7055@myunghoj-Precision-5530/
> >
> > I apply this patch, compile and test again. No more trace this time. Looks like this
> > patch works and it will fix this bug.
> >
> > Fix:
> >
> > This patch will fix this bug:
> >
> > https://lore.kernel.org/linux-bluetooth/20190212083645.GA7055@myunghoj-Precision-5530/
> >
> > This patch will check to see if tiocmget or tiocmset is null in hci_uart_tty_open().
> > If either are null -EOPNOTSUPP is returned.
> >
>
>
> Hi Jiunn,
>
> Don't worry about this bug. Analysis is done on this and fix has been
> identified. There is no need do analysis on this one.
>
> You have done the RCU documentation work and connected with RCU team.
> You could look into one of the rcu related issues for analysis.
>
>
> thanks,
> -- Shuah
>
Hello Shuah,
Okay--will do. I will look into one of the RCU related issues and provide and
analysis.
Thanks Shuah.
Jiunn
>
More information about the Linux-kernel-mentees
mailing list