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

Powered by Openwall GNU/*/Linux Powered by OpenVZ