CVE-2026-31470

What it actually does

This Linux kernel flaw affects Intel TDX guest attestation handling in the tdx-guest driver. A host-controlled quote response length, quote_buf->out_len, was not sufficiently validated before the guest kernel copied quote data to guest userspace. A malicious or compromised host, or a race affecting the host-provided response, could cause the guest to read beyond the pages allocated for the quote buffer, up to TSM_REPORT_OUTBLOB_MAX. The practical impact is an out-of-bounds kernel memory read that may disclose guest memory to a local guest user or to an external attestation service if the quote is forwarded. In some deployments exposing per-container configfs TSM report interfaces, the leak may also cross container isolation boundaries. Availability impact is also possible if malformed lengths or races trigger kernel faults or instability.

Why it matters to the business

Organizations running confidential-computing workloads with Linux guests on Intel TDX could unintentionally disclose sensitive guest memory through the remote attestation flow, undermining the isolation guarantees those environments are meant to provide. The risk is most relevant where guest attestation is exposed to users, services, or containers, or where the infrastructure host cannot be fully trusted. Although EPSS is currently very low and there is no known KEV listing or mature public exploit signal, the confidentiality impact is high for regulated or sensitive workloads because attestation data may be sent outside the guest to verification services.

How an attack unfolds

An attacker needs influence over the TDX host-side quote response path, or the ability to race or manipulate the host-controlled response length supplied to the guest. The attacker causes the host to report an output length larger than the guest-allocated quote buffer while a local user or service in the guest requests a TDX attestation quote through the kernel TSM/configfs interface. Because the vulnerable kernel trusted the host-controlled length, it could copy more bytes than were actually allocated for the quote. Those extra bytes come from adjacent guest memory and are returned to guest userspace as part of the quote blob. If the local attestation agent then forwards the quote to an attestation server, the leaked memory may leave the guest boundary. In containerized deployments exposing per-container TSM report interfaces, a container that can request reports may receive data beyond its intended isolation boundary.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the TDX guest quote buffer length validation. The fix validates the host-controlled quote_buf->out_len before copying quote data to userspace and handles race conditions where the host response may change while the guest consumes it. If vendor-specific fixed kernel package versions are not yet available, track security advisories from the Linux distribution or appliance vendor and apply the first kernel update that references this tdx-guest / TSM report outblob fix. As interim mitigation, restrict access to TDX attestation report interfaces, avoid exposing per-container TSM report/configfs interfaces to untrusted workloads, limit who can trigger attestation quote generation, and treat attestation quote blobs from vulnerable guests as potentially containing unintended memory. Where feasible, run sensitive TDX guests only on trusted host infrastructure until patched.

How to confirm the fix worked

Confirm the running kernel includes the fix from the relevant Linux distribution or upstream stable branch. Validate by checking the installed and booted kernel package version against the vendor advisory, not only by checking that an update is installed on disk. Review whether Intel TDX guest support and the TSM/configfs report interface are enabled and accessible. Confirm access controls prevent untrusted users or containers from reading or creating TSM report quote outputs. Functional validation should include generating an attestation report after patching and confirming normal quote generation still works. Negative testing, if performed in a lab only, should verify that oversized or inconsistent host-provided quote lengths are rejected or bounded rather than copied to userspace.

Typical attack path

1. Identify a Linux guest running in an Intel TDX environment with the vulnerable tdx-guest attestation code.
2. Gain the ability to influence the host-side quote response or operate from a malicious/compromised host layer.
3. Wait for, trigger, or induce a guest attestation quote request through the TSM/configfs report interface.
4. Return or race-modify a host-controlled quote output length that exceeds the guest's allocated quote buffer.
5. Cause the guest kernel to copy out-of-bounds bytes from memory adjacent to the quote buffer into userspace.
6. Collect the malformed quote output locally or from an attestation service that receives forwarded quote blobs.
7. Inspect the leaked bytes for secrets, configuration data, tenant/container data, or other sensitive memory contents.

How to detect it

There is unlikely to be a reliable post-exploitation indicator because the vulnerable behavior occurs inside normal TDX attestation quote generation and may produce valid-looking quote blobs with extra data. Detection should focus on exposure and suspicious attestation activity. Review kernel version inventory for vulnerable TDX guest systems, audit access to TSM/configfs report interfaces, and examine auditd, EDR, shell history, container runtime logs, and attestation-agent logs for unusual users, containers, or processes repeatedly creating or reading TSM report quote outputs. Review attestation service logs for anomalously large quote blobs, malformed quote submissions, repeated quote-generation failures, or unexpected principals submitting quotes. Check kernel logs for tdx-guest, TSM, configfs, or attestation-related warnings, crashes, page faults, or oops events around quote generation. If exploitation is suspected, treat attestation quote payloads and logs from affected systems as sensitive because they may contain leaked memory.

What your security team should do

• Prioritize patching Linux kernels on Intel TDX guest systems, especially systems performing remote attestation for sensitive or regulated workloads.
• Inventory where TDX guest attestation and configfs TSM report interfaces are enabled, including container platforms that may expose per-container report interfaces.
• Restrict permissions to TSM/configfs attestation report paths so only trusted attestation agents can request and read quote blobs.
• Review attestation agents and services to ensure quote blobs from vulnerable systems are not logged, retained, or forwarded more broadly than necessary.
• If the host infrastructure is not fully trusted, treat vulnerable TDX guest attestation output as a potential memory-disclosure channel until patched.
• Monitor distribution advisories for exact fixed kernel versions and ensure systems are rebooted into the patched kernel after updating.
• Because there is no known public exploitation or KEV listing and EPSS is low, prioritize based on TDX usage and sensitivity of protected workloads rather than internet exposure alone.