Re: CVE-2026-68480: x86/bugs: Make Safe-RET robust against interrupt injection

On 06/08/2026 19:41, Greg Kroah-Hartman wrote:
> From: Greg Kroah-Hartman <[email protected]>
> 
> Description
> ===========
> 
> In the Linux kernel, the following vulnerability has been resolved:
> 
> x86/bugs: Make Safe-RET robust against interrupt injection
> 
> An attacker injecting interrupts while the Safe-RET mitigation executes
> on machines affected by SRSO can neutralize the safe return sequence,
> potentially leading to data leakage through speculative execution.
> 
> Fixup register state as if the Safe-RET sequence executed successfully
> by "emulating" it, in a manner of speaking, and avoid executing a RET
> instruction after returning from the interrupt.
> 
> The Linux kernel CVE team has assigned CVE-2026-68480 to this issue.
> 
> 
> Affected and fixed versions
> ===========================
> 
> 	Fixed in 5.10.263 with commit 9de1a49e8f1fbf7c372902573a27a97d4ab4d0af
> 	Fixed in 5.15.214 with commit 9c0b8105e919be5208c81d5516a194a28c58fe1e
> 	Fixed in 6.1.181 with commit 95b08cdd603fe79d2e9d5212fbb13d577c835f4f
> 	Fixed in 6.6.149 with commit 608c8f5dccaaf8b8d2b28c0fbdd439d144be62b0

I hope I did not overlooked something, but at least the 6.6 backport seems
broken to me as it #ifdef guards the fixes on CONFIG_MITIGATION_SRSO, but that
config name is only used in v6.9+ since a033eec9a06ce ("x86/bugs: Rename
CONFIG_CPU_SRSO             => CONFIG_MITIGATION_SRSO") [0] FWICT, i.e. before
that version it was named CONFIG_CPU_SRSO. So shouldn't be that be used here
for all the older pre-v6.9 backports above?

[0]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a033eec9a06ce25388e71fa1e888792a718b9c17

> 	Fixed in 6.18.43 with commit bfe7f9993467ba431b2731437949ac1e2634e771
> 	Fixed in 7.1.7 with commit 61649a2d61cb0dbc673f0f232f0f0c298bf50442
> 

> Mitigation
> ==========
> 
> The Linux kernel CVE team recommends that you update to the latest
> stable kernel version for this, and many other bugfixes.  Individual
> changes are never tested alone, but rather are part of a larger kernel
> release.  Cherry-picking individual commits is not recommended or
> supported by the Linux kernel community at all.  If however, updating to
> the latest release is impossible, the individual changes to resolve this
> issue can be found at these commits:
> 	https://git.kernel.org/stable/c/9de1a49e8f1fbf7c372902573a27a97d4ab4d0af
> 	https://git.kernel.org/stable/c/9c0b8105e919be5208c81d5516a194a28c58fe1e
> 	https://git.kernel.org/stable/c/95b08cdd603fe79d2e9d5212fbb13d577c835f4f
> 	https://git.kernel.org/stable/c/608c8f5dccaaf8b8d2b28c0fbdd439d144be62b0
> 	https://git.kernel.org/stable/c/bfe7f9993467ba431b2731437949ac1e2634e771
> 	https://git.kernel.org/stable/c/61649a2d61cb0dbc673f0f232f0f0c298bf50442
> 	https://git.kernel.org/stable/c/7e7f81cf6f5ca3311e526308f55d7c54d3ba71f9