Regarding the bug in FreeBSD kernel driver(s)
Ian Lepore
ian at freebsd.org
Tue Aug 13 20:09:03 UTC 2019
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
More information about the freebsd-arch
mailing list