Re: [PATCH v2 1/2] x86/uaccess: Extend CMPXCHG user helpers to 128-bit operands

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The 32-bit stub for `__try_cmpxchg128_user_asm` incorrectly evaluates to 1 (success) instead of 0 (failure), silently skipping emulation while falsely signaling a successful memory update.
--

commit 11b4c82317b376374b32df0435151f876d6239e5
Author: Sairaj Kodilkar <sarunkod@amd.com>

x86/uaccess: Extend CMPXCHG user helpers to 128-bit operands

This commit extends the user CMPXCHG helpers to support 16-byte operands
on x86-64 using the cmpxchg16b instruction. It also adds a 32-bit stub
that is intended to always return failure since cmpxchg16b requires
64-bit GPRs.

> diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
> index 367297b188c39..123755d471099 100644
> --- a/arch/x86/include/asm/uaccess.h
> +++ b/arch/x86/include/asm/uaccess.h

[ ... ]

> @@ -551,11 +594,18 @@ do {										\
>  
>  extern void __try_cmpxchg_user_wrong_size(void);
>  
> -#ifndef CONFIG_X86_32
> +#ifdef CONFIG_X86_32
> +/* Always fail on 32 bit arch as it do not support 128 cmpxchg (i.e. cmpxchg16b
> + * instruction).
> + */
> +#define __try_cmpxchg128_user_asm(_ptr, _pold, _new, label) (1)

[Severity: Medium]
Does this 32-bit stub correctly signal failure?

Since this macro evaluates to 1, won't the surrounding unsafe_try_cmpxchg_user
macro treat this as success (true) rather than failure (false)?

This could cause the wrapper to negate the value and return 0 (success) to the
caller, falsely signaling a successful memory exchange without actually
updating memory or the old value. Even though there are no current 32-bit
callers using a 16-byte operand, should this evaluate to 0 instead of 1 to
ensure theoretical future callers don't encounter a silent atomicity break?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260706063035.1139-1-sarunkod@amd.com?part=1