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
next prev parent reply other threads:[~2024-12-14 7:47 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-29 19:33 GPM & Emacs broken in Linux 6.7 -- ok to relax check? Jared Finder
2024-11-29 19:50 ` 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-02-23 20:54 ` [PATCH] tty: Require CAP_SYS_ADMIN for all usages of TIOCL_SELMOUSEREPORT Günther Noack
2025-03-07 10:16 ` Günther Noack
2025-03-07 11:05 ` Greg Kroah-Hartman
2025-03-07 13:55 ` Günther Noack
2025-03-07 14:31 ` Greg Kroah-Hartman
2025-01-12 13:14 ` [PATCH v2] tty: Permit some TIOCL_SETSEL modes without CAP_SYS_ADMIN 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.