From: Florent Revest <revest@chromium.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
catalin.marinas@arm.com, anshuman.khandual@arm.com,
joey.gouly@arm.com, mhocko@suse.com, keescook@chromium.org,
david@redhat.com, peterx@redhat.com, izbyshev@ispras.ru,
broonie@kernel.org, szabolcs.nagy@arm.com, kpsingh@kernel.org,
gthelen@google.com, toiwoton@gmail.com, ayush.jain3@amd.com,
stable@vger.kernel.org
Subject: Re: [PATCH v4 4/6] mm: Make PR_MDWE_REFUSE_EXEC_GAIN an unsigned long
Date: Fri, 22 Sep 2023 15:10:47 +0200 [thread overview]
Message-ID: <CABRcYmJzWLQ2jPH6WmugUrePX+=JMo5iqP0S=U4n191GCm9ChA@mail.gmail.com> (raw)
In-Reply-To: <20230921182910.2fcce58b27b23f767050033c@linux-foundation.org>
On Fri, Sep 22, 2023 at 3:29 AM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Mon, 28 Aug 2023 17:08:56 +0200 Florent Revest <revest@chromium.org> wrote:
>
> > Defining a prctl flag as an int is a footgun because on a 64 bit machine
> > and with a variadic implementation of prctl (like in musl and glibc),
> > when used directly as a prctl argument, it can get casted to long with
> > garbage upper bits which would result in unexpected behaviors.
> >
> > This patch changes the constant to an unsigned long to eliminate that
> > possibilities. This does not break UAPI.
> >
> > Fixes: b507808ebce2 ("mm: implement memory-deny-write-execute as a prctl")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Florent Revest <revest@chromium.org>
> > Suggested-by: Alexey Izbyshev <izbyshev@ispras.ru>
> > Reviewed-by: David Hildenbrand <david@redhat.com>
> > Reviewed-by: Kees Cook <keescook@chromium.org>
> > Acked-by: Catalin Marinas <catalin.marinas@arm.com>
>
> Why is this being offered to -stable? Does it fix any known problem?
The background for this was discussed in these threads:
v1: https://lore.kernel.org/all/66900d0ad42797a55259061f757beece@ispras.ru/
v2: https://lore.kernel.org/all/d7e3749c-a718-df94-92af-1cb0fecab772@redhat.com/
Cc-ing stable was suggested by David and Alexey:
> On Mon, May 22, 2023 at 8:58 PM Alexey Izbyshev <izbyshev@ispras.ru> wrote:
> > On 2023-05-22 19:22, David Hildenbrand wrote:
> > > Which raises the question if we want to tag this here with a "Fixes"
> > > and eventually cc stable (hmm ...)?
> >
> > Yes, IMO the faster we propagate this change, the better.
>
> Okay, will do
I think that a stable backport would be "nice to have": to reduce the
chances that users build binaries that could end up with garbage bits
in their MDWE prctl arguments. We are not aware of anyone having yet
encountered this corner case with MDWE prctls but a backport would
reduce the likelihood it happens, since this sort of issues has
happened with other prctls. But If this is perceived as a backporting
burden, I suppose we could also live without a stable backport.
next prev parent reply other threads:[~2023-09-22 13:11 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-28 15:08 [PATCH v4 0/6] MDWE without inheritance Florent Revest
2023-08-28 15:08 ` [PATCH v4 1/6] kselftest: vm: Fix tabs/spaces inconsistency in the mdwe test Florent Revest
2023-08-28 15:08 ` [PATCH v4 2/6] kselftest: vm: Fix mdwe's mmap_FIXED test case Florent Revest
2023-08-28 15:08 ` [PATCH v4 3/6] kselftest: vm: Check errnos in mdwe_test Florent Revest
2023-08-28 18:45 ` Kees Cook
2023-09-21 9:51 ` Catalin Marinas
2023-08-28 15:08 ` [PATCH v4 4/6] mm: Make PR_MDWE_REFUSE_EXEC_GAIN an unsigned long Florent Revest
2023-09-22 1:29 ` Andrew Morton
2023-09-22 13:10 ` Florent Revest [this message]
2023-08-28 15:08 ` [PATCH v4 5/6] mm: Add a NO_INHERIT flag to the PR_SET_MDWE prctl Florent Revest
2023-09-22 1:33 ` Andrew Morton
2023-10-03 15:52 ` Florent Revest
2023-08-28 15:08 ` [PATCH v4 6/6] kselftest: vm: Add tests for no-inherit memory-deny-write-execute Florent Revest
2023-08-28 18:45 ` Kees Cook
2023-09-20 19:56 ` [PATCH v4 0/6] MDWE without inheritance Florent Revest
2023-09-21 9:52 ` Catalin Marinas
2023-09-21 9:57 ` Florent Revest
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='CABRcYmJzWLQ2jPH6WmugUrePX+=JMo5iqP0S=U4n191GCm9ChA@mail.gmail.com' \
--to=revest@chromium.org \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=ayush.jain3@amd.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=david@redhat.com \
--cc=gthelen@google.com \
--cc=izbyshev@ispras.ru \
--cc=joey.gouly@arm.com \
--cc=keescook@chromium.org \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=peterx@redhat.com \
--cc=stable@vger.kernel.org \
--cc=szabolcs.nagy@arm.com \
--cc=toiwoton@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).