archive mirror
 help / color / mirror / Atom feed
From: Paul Fulghum <>
To: Arnd Bergmann <>
Cc: "Hyunwoo Kim" <>,
	"Greg Kroah-Hartman" <>,
	"Ilpo Järvinen" <>,,
	"Dominik Brodowski" <>
Subject: Re: [PATCH] pcmcia: synclink_cs: Fix use-after-free in mgslpc_ioctl()
Date: Tue, 13 Sep 2022 08:14:01 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

This has been out of production for almost 20 years. It was never a large seller. I do not have the hardware. The chance of one still being in operation someplace is close to zero.

The best solution is to remove this driver from the kernel. Two other obsolete SyncLink drivers were removed a year ago. This would be a good opportunity to remove synclink_cs.c (PCMCIA)

The current SyncLink driver is synclink_gt.c (PCI/PCIe hardware), which is still sold and supported.

> On Sep 13, 2022, at 7:59 AM, Arnd Bergmann <> wrote:
> 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 <>
> 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
>> drivers/char/pcmcia/synclink_cs.c.
>> 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
>   Arnd

  reply	other threads:[~2022-09-13 16:22 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
2022-09-13 15:14   ` Paul Fulghum [this message]
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

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:

* 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).