lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <41b47e38.6ddb4.19c3ccb8e4d.Coremail.duoming@zju.edu.cn>
Date: Sun, 8 Feb 2026 18:28:19 +0800 (GMT+08:00)
From: duoming@....edu.cn
To: "Greg KH" <gregkh@...uxfoundation.org>
Cc: linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org,
	jikos@...nel.org, dsterba@...e.com, jirislaby@...nel.org,
	kuba@...nel.org, alexander.deucher@....com,
	akpm@...ux-foundation.org, pkshih@...ltek.com, tglx@...nel.org,
	mingo@...nel.org
Subject: Re: [PATCH] tty: ipwireless: Fix use-after-free in tasklet during
 device removal

On Sun, 8 Feb 2026 07:38:00 +0100 Greg KH wrote:
> > When IPWireless PCMCIA card is being detached, the ipw_hardware is
> > deallocated in ipwireless_hardware_free(). However, the hw->tasklet may
> > still be running or pending, leading to use-after-free bugs when the
> > already freed ipw_hardware is accessed again in ipwireless_do_tasklet().
> 
> Nice, do you have this hardware to test this with?

I don't have the real hardware. In order to reproduce the bug, I simulate 
the IPWireless PCMCIA card in the qemu by allocating and configuring the 
necessary resources(I/O ports, memory regions, interrupts and so on) to
correspond with the hardware expected by the driver in the initialization 
code of the virtual device.

> > 
> > One race condition scenario is as follows:
> > 
> > CPU 0 (cleanup)               | CPU 1 (interrupt)
> > ipwireless_hardware_free()    | ipwireless_interrupt()
> >   ipwireless_stop_interrupts()|   ipwireless_handle_v1_interrupt()
> >     do_close_hardware()       |     tasklet_schedule()
> >       synchronize_irq()       |
> >   kfree(hw) //FREE            | ipwireless_do_tasklet() //handler
> >                               |   hw = from_tasklet() //USE
> >                               |   hw-> //USE
> > 
> > Fix this by ensuring hw->tasklet is properly canceled before ipw_hardware
> > is released. Add tasklet_kill() in ipwireless_stop_interrupts() to
> > synchronize with any pending or running tasklet. Since do_close_hardware()
> > could prevent further interrupts, place tasklet_kill() after it to avoid
> > the tasklet being rescheduled by ipwireless_interrupt().
> 
> How was this issue found and tested?

The issue was found by static analysis. I test it through the following steps:
1. Simulating the IPWireless PCMCIA device in the qemu and enable it to trigger interrupts.
2. Controlling the removal and attachment of device via sysfs.
3. Triggering interrupts by writing data to device registers via /dev/mem memory mapping
   in userspace.
4. In order to ensure that there are unfinished tasklet during the removal process, I
   manually inject delays such as mdelay() into tasklet handler.

> > Fixes: 099dc4fb6265 ("ipwireless: driver for PC Card 3G/UMTS modem")
> > Signed-off-by: Duoming Zhou <duoming@....edu.cn>
> 
> No CC: stable?  Why not?

Thanks for checking, You are right, it should go to the stable.

Best regards,
Duoming Zhou

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ