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 --- include/uapi/linux/prctl.h | 2 +- tools/include/uapi/linux/prctl.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/prctl.h b/include/uapi/linux/prctl.h index 3c36aeade991..9a85c69782bd 100644 --- a/include/uapi/linux/prctl.h +++ b/include/uapi/linux/prctl.h @@ -283,7 +283,7 @@ struct prctl_mm_map {
/* Memory deny write / execute */ #define PR_SET_MDWE 65 -# define PR_MDWE_REFUSE_EXEC_GAIN 1 +# define PR_MDWE_REFUSE_EXEC_GAIN (1UL << 0)
#define PR_GET_MDWE 66
diff --git a/tools/include/uapi/linux/prctl.h b/tools/include/uapi/linux/prctl.h index 3c36aeade991..9a85c69782bd 100644 --- a/tools/include/uapi/linux/prctl.h +++ b/tools/include/uapi/linux/prctl.h @@ -283,7 +283,7 @@ struct prctl_mm_map {
/* Memory deny write / execute */ #define PR_SET_MDWE 65 -# define PR_MDWE_REFUSE_EXEC_GAIN 1 +# define PR_MDWE_REFUSE_EXEC_GAIN (1UL << 0)
#define PR_GET_MDWE 66
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?
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.
linux-stable-mirror@lists.linaro.org
-
Andrew Morton -
Florent Revest