From: "Arnd Bergmann" <firstname.lastname@example.org>
To: "Hyunwoo Kim" <email@example.com>,
"Greg Kroah-Hartman" <firstname.lastname@example.org>,
"Ilpo Järvinen" <email@example.com>
"Dominik Brodowski" <firstname.lastname@example.org>,
"Paul Fulghum" <email@example.com>
Subject: Re: [PATCH] pcmcia: synclink_cs: Fix use-after-free in mgslpc_ioctl()
Date: Tue, 13 Sep 2022 16:59:29 +0200 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On Tue, Sep 13, 2022, at 7:20 AM, Hyunwoo Kim wrote:
> A race condition may occur if the user physically removes
> the pcmcia device while calling ioctl() for this tty device node.
> This is a race condition between the mgslpc_ioctl() function and
> the mgslpc_detach() function, which may eventually result in UAF.
> So, add a refcount check to mgslpc_detach() to free the structure
> after the tty device node is close()d.
> Signed-off-by: Hyunwoo Kim <email@example.com>
I think both your analysis and your patch are correct.
You might want to spell out use-after-free in the changelog
text, especially if you have a tool that finds more of these.
> I think I've probably found a race-condition-to-UAF vulnerability in
> However, this device driver is a pcmcia_driver based driver.
> I haven't been able to get this old pcmcia adapter/device.
> If you don't mind, I'd like to ask the Linux kernel community to test if
> this vulnerability actually triggers.
Adding Paul Fulghum as the original driver author and Dominik
Brodowski as the PCMCIA maintainer to Cc, if anyone still has
the hardware, it would be one of them.
has the full email for reference.
Even if nobody has the hardware, we could just apply the patch
anyway. Alternatively, we could take a pass at removing most
of the pcmcia_driver instances from the kernel including this
one. Dominik has previously brought up phasing out the
16-bit PCMCIA support altogether at some point, and we may
as well start by removing the ones that have no apparent users
any more, at least that might avoid spending much time on
fixing bugs that nobody cares about.
I'm fairly sure the embedded users mostly care about CF storage
cards, which is the one driver that definitely has to stay.
Most other pcmcia drivers predate the git history, though there
are a few that were only added in the past decade, these would
be the most likely to still be in use:
v5.2-rc1-82-g8674a8aa2c39 scsi: fdomain: Add PCMCIA support
v4.9-rc3-54-gf2ed287bcc90 char/pcmcia: add scr24x_cs chip card interface driver
v3.3-rc5-882-g2b61972b7421 can: sja1000: add support for PEAK-System PCMCIA card
v3.1-rc7-1048-gfd734c6f25ae can/sja1000: add driver for EMS PCMCIA card
v2.6.37-3908-g0a0b7a5f7a04 can: add driver for Softing card
next prev parent reply other threads:[~2022-09-13 16:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-13 5:20 [PATCH] pcmcia: synclink_cs: Fix use-after-free in mgslpc_ioctl() Hyunwoo Kim
2022-09-13 14:59 ` Arnd Bergmann [this message]
2022-09-13 15:14 ` Paul Fulghum
2022-09-13 15:43 ` Hyunwoo Kim
2022-09-15 2:08 ` Hyunwoo Kim
2022-09-15 7:35 ` Arnd Bergmann
2022-09-15 8:02 ` Dominik Brodowski
2022-09-15 9:00 ` Hyunwoo Kim
2022-09-16 5:03 ` Hyunwoo Kim
2022-09-15 14:05 ` Harald Welte
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).