linux-kernel - Re: [PATCH 1/1] tty: n_gsm: Avoid sleeping during .write() whilst atomic

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2023100457-entail-freefall-06fd@gregkh>
Date:   Wed, 4 Oct 2023 08:04:15 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Lee Jones <lee@...nel.org>
Cc:     linux-kernel@...r.kernel.org,
        Daniel Starke <daniel.starke@...mens.com>,
        Fedor Pchelkin <pchelkin@...ras.ru>,
        Jiri Slaby <jirislaby@...nel.org>,
        linux-serial@...r.kernel.org,
        syzbot+5f47a8cea6a12b77a876@...kaller.appspotmail.com
Subject: Re: [PATCH 1/1] tty: n_gsm: Avoid sleeping during .write() whilst
 atomic

On Tue, Oct 03, 2023 at 07:55:00PM +0100, Lee Jones wrote:
> On Tue, 03 Oct 2023, Greg Kroah-Hartman wrote:
> 
> > On Tue, Oct 03, 2023 at 06:00:20PM +0100, Lee Jones wrote:
> > > The important part of the call stack being:
> > > 
> > >   gsmld_write()             # Takes a lock and disables IRQs
> > >     con_write()
> > >       console_lock()
> > 
> > Wait, why is the n_gsm line discipline being used for a console?
> > 
> > What hardware/protocol wants this to happen?
> > 
> > gsm I thought was for a very specific type of device, not a console.
> > 
> > As per:
> > 	https://www.kernel.org/doc/html/v5.9/driver-api/serial/n_gsm.html
> > this is a specific modem protocol, why is con_write() being called?
> 
> What it's meant for and what random users can make it do are likely to
> be quite separate questions.  This scenario is user driven and can be
> replicated simply by issuing a few syscalls (open, ioctl, write).

I would recommend that any distro/system that does not want to support
this specific hardware protocol, just disable it for now (it's marked as
experimental too), if they don't want to deal with the potential
sleep-while-atomic issue.

> > And Lee, you really don't have this hardware, right?  So why are you
> > dealing with bug reports for it?  :)
> 
> 'cos Syzkaller.

Ah, yeah, fake report, no real issue here then :)

thanks,

greg k-h