From: Greg KH <gregkh@linuxfoundation.org>
To: duoming@zju.edu.cn
Cc: linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
jikos@kernel.org, dsterba@suse.com, jirislaby@kernel.org,
kuba@kernel.org, alexander.deucher@amd.com,
akpm@linux-foundation.org, pkshih@realtek.com, tglx@kernel.org,
mingo@kernel.org
Subject: Re: [PATCH] tty: ipwireless: Fix use-after-free in tasklet during device removal
Date: Sun, 8 Feb 2026 12:00:08 +0100 [thread overview]
Message-ID: <2026020859-caretaker-duckbill-0fb3@gregkh> (raw)
In-Reply-To: <41b47e38.6ddb4.19c3ccb8e4d.Coremail.duoming@zju.edu.cn>
On Sun, Feb 08, 2026 at 06:28:19PM +0800, duoming@zju.edu.cn wrote:
> 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.
I wonder if this device even is still around, given that pcmcia is all
but dead for a very long time.
> > > 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.
So this is with the bind/unbind logic, or some other way? If you are
unloading the driver, that is something that only root can do, and this
is a debugging facility, not a "real" way to control drivers and devices
(yes, the virt drivers abuse this to no end, every time I see this I
laugh...)
> 3. Triggering interrupts by writing data to device registers via /dev/mem memory mapping
> in userspace.
Interrupts would not happen if the device is removed. Or is this only
if the driver is unbound?
> 4. In order to ensure that there are unfinished tasklet during the removal process, I
> manually inject delays such as mdelay() into tasklet handler.
That's a lot of work for a piece of obsolete hardware, but hey, thanks
for doing this!
> > > Fixes: 099dc4fb6265 ("ipwireless: driver for PC Card 3G/UMTS modem")
> > > Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
> >
> > No CC: stable? Why not?
>
> Thanks for checking, You are right, it should go to the stable.
Let's see what the maintainers of this driver say.
thanks,
greg k-h
next prev parent reply other threads:[~2026-02-08 11:00 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-08 6:25 [PATCH] tty: ipwireless: Fix use-after-free in tasklet during device removal Duoming Zhou
2026-02-08 6:38 ` Greg KH
2026-02-08 10:28 ` duoming
2026-02-08 11:00 ` Greg KH [this message]
2026-02-08 13:57 ` duoming
2026-02-08 14:34 ` Greg KH
2026-02-08 14:53 ` duoming
2026-02-08 14:58 ` Greg KH
2026-02-08 17:25 ` Jiri Kosina
2026-02-09 10:21 ` David Sterba
2026-02-17 8:03 ` Jiri Slaby
2026-02-18 15:23 ` David Sterba
2026-03-09 11:18 ` Qingfang Deng
2026-03-09 11:25 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2026020859-caretaker-duckbill-0fb3@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=akpm@linux-foundation.org \
--cc=alexander.deucher@amd.com \
--cc=dsterba@suse.com \
--cc=duoming@zju.edu.cn \
--cc=jikos@kernel.org \
--cc=jirislaby@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=pkshih@realtek.com \
--cc=tglx@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.