Re: [PATCH 3/4] mm: synchronize saved_auxv access with arg_lock

[Kees Cook]

On Mon, Feb 09, 2026 at 07:06:04PM +0000, Andrei Vagin 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.
> 
> Signed-off-by: Andrei Vagin <avagin@xxxxxxxxxx>
> ---
>  fs/exec.c      |  8 ++++++--
>  fs/proc/base.c | 12 +++++++++---
>  kernel/fork.c  |  7 ++++++-
>  kernel/sys.c   | 29 ++++++++++++++---------------
>  4 files changed, 35 insertions(+), 21 deletions(-)
> 
> diff --git a/fs/exec.c b/fs/exec.c
> index 7401efbe4ba0..d7e3ad8c8051 100644
> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -1793,6 +1793,7 @@ static int bprm_execve(struct linux_binprm *bprm)
>  
>  static void inherit_hwcap(struct linux_binprm *bprm)
>  {
> +	struct mm_struct *mm = current->mm;
>  	int i, n;
>  
>  #ifdef ELF_HWCAP4
> @@ -1805,10 +1806,12 @@ static void inherit_hwcap(struct linux_binprm *bprm)
>  	n = 1;
>  #endif
>  
> +	spin_lock(&mm->arg_lock);
>  	for (i = 0; n && i < AT_VECTOR_SIZE; i += 2) {
> -		long val = current->mm->saved_auxv[i + 1];
> +		unsigned long type = mm->saved_auxv[i];
> +		unsigned long val = mm->saved_auxv[i + 1];

Ah, I see the signed/unsigned is fixed here. :)

I don't see anything in here that is fast-path, so the locking seems
fine to me.

-- 
Kees Cook