Date: Tue, 13 Aug 2019 14:08:58 -0600 From: Ian Lepore <ian@freebsd.org> To: Neeraj Pal <neerajpal09@gmail.com>, freebsd-arch@freebsd.org Cc: Hans Petter Selasky <hselasky@FreeBSD.org> Subject: Re: Regarding the bug in FreeBSD kernel driver(s) Message-ID: <cb4108b6e8494259e31d1ab7d5163ae77a2a2116.camel@freebsd.org> In-Reply-To: <CANi4_RUcNt8Z0Gw1DqoOCAYt61kfhv2aoz1v9snrB_Jg38z_zQ@mail.gmail.com> References: <CANi4_RUcNt8Z0Gw1DqoOCAYt61kfhv2aoz1v9snrB_Jg38z_zQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2019-08-14 at 01:10 +0530, Neeraj Pal wrote:
> Hi there,
>
> After discussing the issue with the security-team, I have posted it
> publicly.
>
> Please find the bug information given below with workaround diff:
>
> I have observed the "NULL pointer dereference" bug inside the FreeBSD
> kernel driver code due to which kernel gets in panic (or DOS) mode
> and then
> it has to reboot.
>
> Actually, this vulnerability resides in lots of kernel drivers like
> "uhub0", "ubt0", "umass0", "run0", "uhid0" etc.
>
> I have tested and observed the panic for following kernel drivers:
>
> - usb,
> - umass (storage),
> - ubt(bluetooth),
> - run0(wifi),
> - uhid
>
> [...]
>
> Please confirm and let me know if any other info required.
>
It appears the problem is limited to usb devices, not all devices in
the system. It looks like the root of the NULL ivars problem is this
code from usb_device.c:
if (device_probe_and_attach(iface->subdev) == 0) {
/*
* The USB attach arguments are only available during probe
* and attach !
*/
uaa->temp_dev = NULL;
device_set_ivars(iface->subdev, NULL);
...
So once a device is attached the first time, its usb ivars are wiped
out. That code was surely written in a time before the devctl stuff
was added to allow disabling/enabling a device on the fly. I'm not
sure whether it will be easy to keep the ivar data around, but if so, I
think that would be the right fix.
The NULL pointer checks in the patches will prevent a kernel panic, but
don't really make devctl enable work properly. Speaking of devctl, you
don't need a program to test this, you can do it from the command line:
devctl disable uhub2
devctl enable uhub2
<panic happens here>
-- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cb4108b6e8494259e31d1ab7d5163ae77a2a2116.camel>