Received-SPF: pass (google.com: domain of oss-security-return-30038-linux.lists.archive=gmail.com@lists.openwall.com designates 193.110.157.125 as permitted sender) client-ip=193.110.157.125;
Mailing-List: contact oss-security-help@lists.openwall.com; run by ezmlm
Precedence: bulk
Reply-To: oss-security@lists.openwall.com
Feedback-ID: i787e41f1:Fastmail
Date: Wed, 17 Apr 2024 08:19:15 +0200
From: Greg KH <greg@kroah.com>
To: oss-security@lists.openwall.com
Message-ID: <2024041743-muskiness-agreeably-5d03@gregkh>
References: <607d5716-128f-44c5-ab52-6dde4ca6e8a4@christopher-kunz.de>
 <20240410211457.GA20881@openwall.com>
 <20240416201602.GA21501@openwall.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240416201602.GA21501@openwall.com>
Subject: Re: [oss-security] New Linux LPE via GSMIOC_SETCONF_DLCI?

On Tue, Apr 16, 2024 at 10:16:02PM +0200, Solar Designer wrote:
> On Wed, Apr 10, 2024 at 11:14:57PM +0200, Solar Designer wrote:
> > On Wed, Apr 10, 2024 at 09:56:33PM +0200, Dr. Christopher Kunz wrote:
> > > 1. YuriiCrimson's version (April 6-ish)
> > > 
> > > It seems to use GSMIOC_SETCONF_DLCI, PoC supposedly works on current Ubuntu 
> > > and Debians, but is stopped by LKRG.
> > > 
> > > PoC and writeup are here: 
> > > https://github.com/YuriiCrimson/ExploitGSM/tree/main
> > 
> > According to YuriiCrimson:
> > 
> > https://twitter.com/YuriiCrimson/status/1778163455075217443
> > 
> > "Exploit 6.4 - 6.5 using race condition in gsm_dlci_config.
> > Exploit for 5.15 - 6.5. using race condition in
> > gsm_dlci_open->gsm_modem_update->gsm_modem_upd_via_msc->gsm_control_wait.
> > We just waiting on gsm_cobtrol_wait and restart config for make free
> > dlci)). So it two zero days."
> > 
> > > 3. ZDI-24-020 / CVE-2023-6546 (January)
> > > 
> > > This also exploits a race condition resulting UAF in the gsm_dlci struct. 
> > > It's a little older.
> > > 
> > > Writeup and PoC: https://github.com/Nassim-Asrir/ZDI-24-020/
> > > 
> > > What do you make of this?
> > 
> > So it sounds like there are 3 different bugs recently found in this same
> > subsystem.  Perhaps someone can follow up with links to relevant commits.
> 
> I'm puzzled by the lack of follow-ups on this, but anyway @FFFVR_
> tweeted they also found (more) vulnerabilities in the n_gsm driver:
> 
> https://twitter.com/FFFVR_/status/1778244738833080571

There has been lots of bugs in this driver once people started running
fuzzing on the code, which is why we applied the following patch last
year as you mention:

> Also relevant is this mainline commit from August 2023:
> 
> tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=67c37756898a
> 
> which is now being backported to stable/longterm kernels:

It's now in the following released kernels:
	4.19.312 5.4.274 5.10.215 5.15.155 6.1.86 6.6

If people are curious in helping out, here's a good summary of the
issues involved from the current maintainer of the driver:
	https://lore.kernel.org/r/DB9PR10MB5881D2170678C169FB42A423E0082@DB9PR10MB5881.EURPRD10.PROD.OUTLOOK.COM

> Subject: Backport of 67c37756898a ("tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc") to older stable series? (at least 6.1.y)
> https://lore.kernel.org/stable/ZhbiWp9DexB_gJh_@eldamar.lan/
> 
> Since there are multiple known unfixed bugs in this driver and since it
> poses unjustified risk on most systems anyway, here are some mitigations
> we can apply:
> 
> 1. At kernel build time, don't enable CONFIG_N_GSM.

I recommend this one, almost no one has this hardware, it is very
specialized, so unless you have hardware that requires it, don't use it.

thanks,

greg k-h