On Mon, Jan 08, 2024 at 02:52:24PM +0000, Lee Jones wrote:
> On Wed, 09 Aug 2023, Greg Kroah-Hartman wrote:
>
> > From: Duoming Zhou <duoming@xxxxxxxxxx>
> >
> > [ Upstream commit 1e7417c188d0a83fb385ba2dbe35fd2563f2b6f3 ]
> >
> > The timer dev->stat_monitor can schedule the delayed work dev->wq and
> > the delayed work dev->wq can also arm the dev->stat_monitor timer.
> >
> > When the device is detaching, the net_device will be deallocated. but
> > the net_device private data could still be dereferenced in delayed work
> > or timer handler. As a result, the UAF bugs will happen.
> >
> > One racy situation is shown below:
> >
> > (Thread 1) | (Thread 2)
> > lan78xx_stat_monitor() |
> > ... | lan78xx_disconnect()
> > lan78xx_defer_kevent() | ...
> > ... | cancel_delayed_work_sync(&dev->wq);
> > schedule_delayed_work() | ...
> > (wait some time) | free_netdev(net); //free net_device
> > lan78xx_delayedwork() |
> > //use net_device private data |
> > dev-> //use |
> >
> > Although we use cancel_delayed_work_sync() to cancel the delayed work
> > in lan78xx_disconnect(), it could still be scheduled in timer handler
> > lan78xx_stat_monitor().
> >
> > Another racy situation is shown below:
> >
> > (Thread 1) | (Thread 2)
> > lan78xx_delayedwork |
> > mod_timer() | lan78xx_disconnect()
> > | cancel_delayed_work_sync()
> > (wait some time) | if (timer_pending(&dev->stat_monitor))
> > | del_timer_sync(&dev->stat_monitor);
> > lan78xx_stat_monitor() | ...
> > lan78xx_defer_kevent() | free_netdev(net); //free
> > //use net_device private data|
> > dev-> //use |
> >
> > Although we use del_timer_sync() to delete the timer, the function
> > timer_pending() returns 0 when the timer is activated. As a result,
> > the del_timer_sync() will not be executed and the timer could be
> > re-armed.
> >
> > In order to mitigate this bug, We use timer_shutdown_sync() to shutdown
> > the timer and then use cancel_delayed_work_sync() to cancel the delayed
> > work. As a result, the net_device could be deallocated safely.
> >
> > What's more, the dev->flags is set to EVENT_DEV_DISCONNECT in
> > lan78xx_disconnect(). But it could still be set to EVENT_STAT_UPDATE
> > in lan78xx_stat_monitor(). So this patch put the set_bit() behind
> > timer_shutdown_sync().
> >
> > Fixes: 77dfff5bb7e2 ("lan78xx: Fix race condition in disconnect handling")
>
> Any idea why this stopped at linux-6.4.y? The aforementioned Fixes:
> commit also exists in linux-6.1.y and linux-5.15.y. I don't see any
> earlier backport attempts or failure reports that would otherwise
> explain this.
Did you try to build it:
drivers/net/usb/lan78xx.c: In function ‘lan78xx_disconnect’:
drivers/net/usb/lan78xx.c:4234:9: error: implicit declaration of function ‘timer_shutdown_sync’ [-Werror=implicit-function-declaration]
4234 | timer_shutdown_sync(&dev->stat_monitor);
| ^~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
That's a good reason to not include it...
Also, is it really an issue or just showing up on a CVE-checker
somewhere? (odds on the latter, based on the author of this commit...)
If anyone really cares about it, I figured they would submit a working
patch :)
thanks,
greg k-h
