public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Jared Finder <jared@finder.org>
Cc: "Günther Noack" <gnoack@google.com>,
	"Jann Horn" <jannh@google.com>, "Hanno Böck" <hanno@hboeck.de>,
	"Jiri Slaby" <jirislaby@kernel.org>,
	linux-hardening@vger.kernel.org, regressions@lists.linux.dev,
	"kernel list" <linux-kernel@vger.kernel.org>
Subject: Re: GPM & Emacs broken in Linux 6.7 -- ok to relax check?
Date: Sat, 14 Dec 2024 08:47:40 +0100	[thread overview]
Message-ID: <2024121418-blazer-valiant-c51a@gregkh> (raw)
In-Reply-To: <ca2a101ccf5ae790dd2cac58ff832922@finder.org>

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

  reply	other threads:[~2024-12-14  7:47 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <ee3ec63269b43b34e1c90dd8c9743bf8@finder.org>
2024-11-29 19:50 ` GPM & Emacs broken in Linux 6.7 -- ok to relax check? Jann Horn
2024-12-03 13:53   ` Günther Noack
2024-12-03 14:07     ` Günther Noack
2024-12-14  5:13       ` Jared Finder
2024-12-14  7:47         ` Greg Kroah-Hartman [this message]
2024-12-16 15:07           ` [PATCH] tty: Permit some TIOCL_SETSEL modes without CAP_SYS_ADMIN Günther Noack
2024-12-16 15:14             ` Greg Kroah-Hartman
2024-12-16 15:17             ` Greg Kroah-Hartman
2024-12-16 15:42               ` Günther Noack
2024-12-21 11:06                 ` Günther Noack
2024-12-21 11:10                   ` [PATCH v2] " Günther Noack
2024-12-22  8:37                     ` Greg Kroah-Hartman
2025-01-10 14:21                   ` Günther Noack
2025-01-10 16:50                     ` Kees Cook
2025-02-08 15:18                       ` Jared Finder
2025-02-08 15:28                         ` Greg KH
2025-02-08 16:03                           ` Jared Finder
2025-02-09  6:49                             ` Greg KH
2025-02-21  0:10                         ` Günther Noack
2025-02-22 21:07                           ` Jared Finder
2025-01-12 13:14                     ` Greg Kroah-Hartman
2024-12-17  9:09             ` [PATCH] " Günther Noack
2024-12-17  8:47     ` GPM & Emacs broken in Linux 6.7 -- ok to relax check? Hanno Böck
2024-12-17  8:49       ` Greg Kroah-Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2024121418-blazer-valiant-c51a@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=gnoack@google.com \
    --cc=hanno@hboeck.de \
    --cc=jannh@google.com \
    --cc=jared@finder.org \
    --cc=jirislaby@kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=regressions@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox