From: sashiko-bot@kernel.org
To: "Sairaj Kodilkar" <sarunkod@amd.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH v4 1/2] x86/uaccess: Extend CMPXCHG user helpers to 128-bit operands
Date: Tue, 08 Sep 2026 08:19:27 +0000 [thread overview]
Message-ID: <20260908081928.2D7D21F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260908074739.10748-2-sarunkod@amd.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] When the host CPU lacks CX16 support, the 16-byte fallback returns a mismatch without updating the old value pointer, violating the cmpxchg API contract and causing infinite retry loops.
--
commit 5f4dae7c1efaa8622accc402392f8d8a532481b4
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 cmpxchg16b. KVM uses this to atomically emulate guest
cmpxchg16b on guest RAM mapped via userspace addresses.
> diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
> --- a/arch/x86/include/asm/uaccess.h
> +++ b/arch/x86/include/asm/uaccess.h
[ ... ]
> @@ -580,6 +634,14 @@ extern void __try_cmpxchg_user_wrong_size(void);
> case 8: __ret = __try_cmpxchg64_user_asm((__force u64 *)(_ptr), (_oldp),\
> (_nval), _label); \
> break; \
> + case 16: \
> + if (boot_cpu_has(X86_FEATURE_CX16)) \
> + __ret = __try_cmpxchg128_user_asm( \
> + (__force u128 *)(_ptr), \
> + (_oldp), (_nval), _label); \
> + else \
> + __ret = 0; \
[Severity: High]
Does setting __ret to 0 here on hardware without CX16 support violate the
cmpxchg API contract?
When boot_cpu_has(X86_FEATURE_CX16) is false, it returns 0 (mismatch) but
fails to fetch the actual memory value and write it into _oldp.
If a guest executes cmpxchg16b on an MMIO address (forcing KVM emulation),
KVM's emulator decodes it and invokes unsafe_try_cmpxchg_user. Because
it returns 0 without updating the pointer, x86_emulate_insn skips
writeback_registers() and returns EMULATION_OK.
The guest registers remain unchanged while EFLAGS shows failure (ZF=0).
Can this cause a denial of service where the guest endlessly retries the
instruction with the same stale registers?
Should this instead use goto _label; to cleanly abort the unsupported
operation, which would cause KVM to properly abort the emulation?
> + break; \
> default: __try_cmpxchg_user_wrong_size(); \
> } \
> __ret; })
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260908074739.10748-1-sarunkod@amd.com?part=1
next prev parent reply other threads:[~2026-09-08 8:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-08 7:47 [PATCH v4 0/2] Add support for cmpxchg16b emulation Sairaj Kodilkar
2026-09-08 7:47 ` [PATCH v4 1/2] x86/uaccess: Extend CMPXCHG user helpers to 128-bit operands Sairaj Kodilkar
2026-09-08 8:19 ` sashiko-bot [this message]
2026-09-08 7:47 ` [PATCH v4 2/2] KVM: x86: Add support for cmpxchg16b emulation Sairaj Kodilkar
2026-09-08 8:21 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260908081928.2D7D21F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=sarunkod@amd.com \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.