Re: [PATCH] pcmcia: synclink_cs: Fix use-after-free in mgslpc_ioctl()

[Paul Fulghum <paulkf@microgate.com>]

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 <arnd@arndb.de> 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 <imv4bel@gmail.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
>> 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.
> https://lore.kernel.org/lkml/20220913052020.GA85241@ubuntu/
> 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