Date: Tue, 09 Aug 2016 10:25:45 -0700 From: John Baldwin <jhb@freebsd.org> To: Hans Petter Selasky <hselasky@freebsd.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r303870 - head/sys/dev/mlx5/mlx5_en Message-ID: <1815980.zoyFBGqzV5@ralph.baldwin.cx> In-Reply-To: <201608090743.u797hF8l000216@repo.freebsd.org> References: <201608090743.u797hF8l000216@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, August 09, 2016 07:43:15 AM Hans Petter Selasky wrote: > Author: hselasky > Date: Tue Aug 9 07:43:15 2016 > New Revision: 303870 > URL: https://svnweb.freebsd.org/changeset/base/303870 > > Log: > Fix for use after free. > > Clear the device description to avoid use after free because the > bsddev is not destroyed when the mlx5en module is unloaded. Only when > the parent mlx5 module is unloaded the bsddev is destroyed. This fixes > a panic on listing sysctls which refer strings in the bsddev after the > mlx5en module has been unloaded. > > Sponsored by: Mellanox Technologies > MFC after: 1 week Hmmm, this seems like it is working around a bug somewhere else. device_detach() calls device_set_driver(dev, NULL) which in turn calls device_set_desc(dev, NULL) which should be clearing the description. You can only be leaking a desc pointer if you aren't detaching the device. Not detaching a device but unloading the module containing part (but apparently not all) of its driver would seem to be fraught with peril. Why are you not detaching the mlx5en0 device when unloading this module? -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1815980.zoyFBGqzV5>