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: <20231004090918.GB9374@google.com>
Date:   Wed, 4 Oct 2023 10:09:18 +0100
From:   Lee Jones <lee@...nel.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.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 Wed, 04 Oct 2023, Greg Kroah-Hartman wrote:

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

n_gsm is available on all the systems I have available.  The mention of
'EXPERIMENTAL' in the module description appears to have zero effect on
whether distros choose to make it available or not.  If you're saying
that we know this module is BROKEN however, then perhaps we should mark
it as such.

> > > 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 :)

Ouch!  The way I see it, the present issue with Syzkaller is that we do
not have the resources to remedy all of the issues it flags.  Passing
off all reports as 'not real issues' is going to make engineers who
decide to work on them feel undervalued and is likely have a detrimental
effect overall.  As an ambassador for young and new people trying to get
into Kernel Engineering in general, is that really the outcome you're
after?

-- 
Lee Jones [李琼斯]