linux-kernel - Re: [PATCH 3/4] mm: synchronize saved_auxv access with arg

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: <ilki5auwqeipwwolu7zgmj2wn2wd5t4saa5mtazn57egz45xbm@j4rl4bufrs2w>
Date: Tue, 10 Feb 2026 10:48:19 +0100
From: Michal Koutný <mkoutny@...e.com>
To: Andrei Vagin <avagin@...gle.com>
Cc: Kees Cook <kees@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>, 
	Cyrill Gorcunov <gorcunov@...il.com>, Mike Rapoport <rppt@...nel.org>, 
	Alexander Mikhalitsyn <alexander@...alicyn.com>, linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org, 
	linux-mm@...ck.org, criu@...ts.linux.dev, Chen Ridong <chenridong@...wei.com>, 
	Christian Brauner <brauner@...nel.org>, David Hildenbrand <david@...nel.org>, 
	Eric Biederman <ebiederm@...ssion.com>, Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Subject: Re: [PATCH 3/4] mm: synchronize saved_auxv access with arg_lock

On Mon, Feb 09, 2026 at 07:06:04PM +0000, Andrei Vagin <avagin@...gle.com> wrote:
> The mm->saved_auxv array stores the auxiliary vector, which can be
> modified via prctl(PR_SET_MM_AUXV) or prctl(PR_SET_MM_MAP). Previously,
> accesses to saved_auxv were not synchronized. This was a intentional
> trade-off, as the vector was only used to provide information to
> userspace via /proc/PID/auxv or prctl(PR_GET_AUXV), and consistency
> between the auxv values left to userspace.
> 
> With the introduction of hardware capability (HWCAP) inheritance during
> execve, the kernel now relies on the contents of saved_auxv to configure
> the execution environment of new processes.  An unsynchronized read
> during execve could result in a new process inheriting an inconsistent
> set of capabilities if the parent process updates its auxiliary vector
> concurrently.
> 
> While it is still not strictly required to guarantee the consistency of
> auxv values on the kernel side, doing so is relatively straightforward.
> This change implements synchronization using arg_lock.

(For the clarification, I didn't consider the lack of synchronization a
blocker after your previous explanation. Nevertheless)

Thanks for explicit sync.

One little nit is a missing hunk like below.


--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -1205,11 +1205,10 @@ struct mm_struct {
                spinlock_t arg_lock; /* protect the below fields */

                unsigned long start_code, end_code, start_data, end_data;
                unsigned long start_brk, brk, start_stack;
                unsigned long arg_start, arg_end, env_start, env_end;
-
                unsigned long saved_auxv[AT_VECTOR_SIZE]; /* for /proc/PID/auxv */

 #ifdef CONFIG_ARCH_HAS_ELF_CORE_EFLAGS
                /* the ABI-related flags from the ELF header. Used for core dump */
                unsigned long saved_e_flags;



> 
> Signed-off-by: Andrei Vagin <avagin@...gle.com>
> ---
>  fs/exec.c      |  8 ++++++--
>  fs/proc/base.c | 12 +++++++++---
>  kernel/fork.c  |  7 ++++++-
>  kernel/sys.c   | 29 ++++++++++++++---------------
>  4 files changed, 35 insertions(+), 21 deletions(-)

I can say
Reviewed-by: Michal Koutný <mkoutny@...e.com>

Download attachment "signature.asc" of type "application/pgp-signature" (266 bytes)