[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2024121418-blazer-valiant-c51a@gregkh>
Date: Sat, 14 Dec 2024 08:47:40 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Jared Finder <jared@...der.org>
Cc: Günther Noack <gnoack@...gle.com>,
Jann Horn <jannh@...gle.com>,
Hanno Böck <hanno@...eck.de>,
Jiri Slaby <jirislaby@...nel.org>, linux-hardening@...r.kernel.org,
regressions@...ts.linux.dev,
kernel list <linux-kernel@...r.kernel.org>
Subject: Re: GPM & Emacs broken in Linux 6.7 -- ok to relax check?
On Fri, Dec 13, 2024 at 09:13:54PM -0800, Jared Finder wrote:
> On 2024-12-03 06:07, Günther Noack wrote:
> > On Tue, Dec 03, 2024 at 02:53:27PM +0100, Günther Noack wrote:
> > > Hanno, you are the original author of this patch and you have done a
> > > more
> > > detailed analysis on the TIOCLINUX problems than me -- do you agree
> > > that this
> > > weakened check would still be sufficient to protect against the
> > > TIOCLINUX
> > > problems? (Or in other words, if we permitted TIOCL_SELPOINTER,
> > > TIOCL_SELCLEAR
> > > and TIOCL_SELMOUSEREPORT for non-CAP_SYS_ADMIN processes, would you
> > > still see a
> > > way to misuse that functionality?)
> >
> > P.S.: For reference, some more detailed reasoning why I think that that
> > proposal
> > would be OK:
> >
> > It would protect at least against the "minittyjack.c" example that was
> > attached
> > to https://www.openwall.com/lists/oss-security/2023/03/14/3
> >
> > The trick used there was:
> >
> > * ioctl() with TIOCLINUX with TIOCL_SETSEL with TIOCL_SELLINE,
> > to make a selection (a.k.a. changing the contents of vc_sel)
> > * ioctl() with TIOCLINUX and TIOCL_PASTESEL to paste the selection.
> > (The implementation for that is in selection.c/paste_selection()
> > and is just copying from vc_sel.)
> >
> > So as long as we are protecting the change to vc_sel, that should be OK
> > in my
> > mind.
>
> It's been silent for about a week and a half here. How long do we wait
> before creating a patch here? This is a regression so I'm assuming we
> shouldn't wait too long.
>
> I'm happy to create the patch if that's helpful. I'd need help with process
> for submitting it for inclusion in the latest kernel as well as backports to
> earlier impacted versions. I've never submitted code to Linux before.
Sure, make a patch and we will be glad to help you out in getting it
accepted if it looks good.
thanks,
greg k-h
Powered by blists - more mailing lists