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>