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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <a8a9fd74-4ee5-4619-8492-be7139e6d48e@www.fastmail.com>
Date:   Tue, 13 Sep 2022 16:59:29 +0200
From:   "Arnd Bergmann" <arnd@...db.de>
To:     "Hyunwoo Kim" <imv4bel@...il.com>,
        "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
        Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Cc:     linux-kernel@...r.kernel.org,
        "Dominik Brodowski" <linux@...inikbrodowski.net>,
        "Paul Fulghum" <paulkf@...rogate.com>
Subject: Re: [PATCH] pcmcia: synclink_cs: Fix use-after-free in mgslpc_ioctl()

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@...il.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ