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

Kees Cook
2026-02-12T23:53:40Z

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@google.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(-)
>
> 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