Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36;
Date:   Thu, 5 Oct 2023 08:26:04 +0100
From:   Lee Jones <lee@kernel.org>
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc:     Jiri Slaby <jirislaby@kernel.org>, linux-kernel@vger.kernel.org,
        Daniel Starke <daniel.starke@siemens.com>,
        Fedor Pchelkin <pchelkin@ispras.ru>,
        linux-serial@vger.kernel.org,
        syzbot+5f47a8cea6a12b77a876@syzkaller.appspotmail.com
Subject: Re: [PATCH 1/1] tty: n_gsm: Avoid sleeping during .write() whilst
 atomic
Message-ID: <20231005072604.GC83257@google.com>
References: <20231003170020.830242-1-lee@kernel.org>
 <2023100320-immorally-outboard-573a@gregkh>
 <20231003185500.GD8453@google.com>
 <2023100457-entail-freefall-06fd@gregkh>
 <20231004090918.GB9374@google.com>
 <2023100425-unwieldy-reaffirm-2a1b@gregkh>
 <20231004125758.GB83257@google.com>
 <1c2afee3-6c1b-4703-8b9a-487f96a2526b@kernel.org>
 <2023100511-unpeeled-dinginess-fefd@gregkh>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2023100511-unpeeled-dinginess-fefd@gregkh>
Precedence: bulk

On Thu, 05 Oct 2023, Greg Kroah-Hartman wrote:

> On Thu, Oct 05, 2023 at 06:59:50AM +0200, Jiri Slaby wrote:
> > On 04. 10. 23, 14:57, Lee Jones wrote:
> > > > > 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.
> > > > 
> > > > Also, I think this requires root to set this line discipline to the
> > > > console, right?  A normal user can't do that, or am I missing a code
> > > > path here?
> > > 
> > > I haven't been testing long, but yes, early indications show that root
> > > is required.
> > 
> > FWIW I concluded to the same yesterday, so I disputed the connected
> > CVE-2023-31082. Waiting for mitre's ack/nack.
> 
> Trying to dispute obviously-wrong CVEs is a never-ending task.
> 
> Personally, it's fun to see who keeps popping up to attempt to resolve
> this issue showing what companies have their security policies dictated
> by a random government authority that can be modified by anyone :)

It's a struggle! :)

-- 
Lee Jones [李琼斯]