Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Subject: Re: [PATCH] pcmcia: synclink_cs: Fix use-after-free in mgslpc_ioctl()
From:   Paul Fulghum <paulkf@microgate.com>
In-Reply-To: <a8a9fd74-4ee5-4619-8492-be7139e6d48e@www.fastmail.com>
Date:   Tue, 13 Sep 2022 08:14:01 -0700
Cc:     Hyunwoo Kim <imv4bel@gmail.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        =?utf-8?Q?Ilpo_J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>,
        linux-kernel@vger.kernel.org,
        Dominik Brodowski <linux@dominikbrodowski.net>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5BBF8723-AF48-4380-B05B-CB3B552322BD@microgate.com>
References: <20220913052020.GA85241@ubuntu>
 <a8a9fd74-4ee5-4619-8492-be7139e6d48e@www.fastmail.com>
To:     Arnd Bergmann <arnd@arndb.de>
Precedence: bulk

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:
>=20
> 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.
>>=20
>> This is a race condition between the mgslpc_ioctl() function and
>> the mgslpc_detach() function, which may eventually result in UAF.
>>=20
>> So, add a refcount check to mgslpc_detach() to free the structure
>> after the tty device node is close()d.
>>=20
>> Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
>=20
> I think both your analysis and your patch are correct.
>=20
> You might want to spell out use-after-free in the changelog
> text, especially if you have a tool that finds more of these.
>=20
>> 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.
>>=20
>> If you don't mind, I'd like to ask the Linux kernel community to test =
if
>> this vulnerability actually triggers.
>=20
> 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.
>=20
> 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.
>=20
> 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:
>=20
> 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
>=20
>   Arnd