Intel CPUs supporting TSX, including Cascade Lake Xeon Scalable - INTEL-SA-00270: Same class of in-flight data leak

Impact

Same class of in-flight data leak as MDS, but reached through a TSX transaction abort - and crucially it works on Cascade Lake, the generation Intel shipped with the MDS_NO silicon fix. That is the operator lesson: the parts you bought specifically because they were 'the fixed ones' were still vulnerable. An attacker samples data another tenant or the host kernel is moving through the fill buffers. Only the attacker needs to use TSX; the victim does not. Cross-hyperthread, so on a shared-SMT fleet it is a direct tenant-boundary break yielding keys, tokens and credentials.

Who can reach it

Unprivileged local code on a TSX-capable CPU, in any guest or container. Cross-hyperthread attacks work because the fill buffers are shared between siblings.

What to do

Microcode/BIOS update plus kernel patch - firmware flash, host reboot, job drain. Then a real choice: (a) tsx=off disables TSX entirely and fully closes it including cross-thread - this is the Linux default and the right call for a multi-tenant operator, and the only workloads that notice are the rare ones using hardware lock elision; or (b) keep TSX and rely on VERW buffer clearing, which leaves cross-hyperthread attacks possible unless you also disable SMT. Choose tsx=off. It costs almost nothing on AI infrastructure workloads and removes both the mitigation overhead and the SMT dilemma.

References