CVE-2023-52874

What it actually does

Missing xor of RSI register in TDX_HYPERCALL asm macro after TDCALL allows untrusted VMM-supplied values to remain in a register that should have been cleared before return to the guest.

Why it matters to the business

Organizations running TDX-protected Linux guests face a small risk of register-value leakage through speculative execution paths, which could aid further attacks in high-security confidential-computing deployments.

How an attack unfolds

An attacker with control of the untrusted VMM supplies a chosen value in RSI before the TDCALL; after the hypercall returns the value is not cleared, allowing speculative execution gadgets inside the guest to observe it.

How to fix it

Apply the kernel patch that adds xor %rsi,%rsi back into the TDX_HYPERCALL macro (commit 2191950d35d8f81620ea8d4e04d983f664fe3a8a) and rebuild or upgrade to a kernel containing that commit.

How to confirm the fix worked

Confirm the presence of the xor instruction immediately after the TDCALL in the __tdx_hypercall assembly; alternatively verify the running kernel contains commit 2191950d35d8f81620ea8d4e04d983f664fe3a8a or later.

Typical attack path

1. Gain control of the host VMM or compromise the TDX module interface
2. Prepare a malicious RSI value before invoking TDX_HYPERCALL
3. Trigger the hypercall path from the guest
4. Use speculative-execution side channels to read the uncleared register value

How to detect it

Review hypervisor and guest kernel logs around TDX hypercall entry points for unexpected register patterns; no public exploitation artifacts are known.

What your security team should do

• Prioritize patching TDX-enabled kernel builds first
• Update all stable kernel trees to the listed fixed commit
• Rebuild and redeploy guest images that use TDX
• Monitor upstream stable branches for the backported fix