UBUNTU-CVE-2025-21632
In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Ensure shadow stack is active before "getting" registers The x86 shadow stack support has its own set of registers. Those registers are XSAVE-managed, but they are "supervisor state components" which means that userspace can not touch them with XSAVE/XRSTOR. It also means that they are not accessible from the existing ptrace ABI for XSAVE state. Thus, there is a new ptrace get/set interface for it. The regset code that ptrace uses provides an ->active() handler in addition to the get/set ones. For shadow stack this ->active() handler verifies that shadow stack is enabled via the ARCH_SHSTK_SHSTK bit in the thread struct. The ->active() handler is checked from some call sites of the regset get/set handlers, but not the ptrace ones. This was not understood when shadow stack support was put in place. As a result, both the set/get handlers can be called with XFEATURE_CET_USER in its init state, which would cause get_xsave_addr() to return NULL and trigger a WARN_ON(). The ssp_set() handler luckily has an ssp_active() check to avoid surprising the kernel with shadow stack behavior when the kernel is not ready for it (ARCH_SHSTK_SHSTK==0). That check just happened to avoid the warning. But the ->get() side wasn't so lucky. It can be called with shadow stacks disabled, triggering the warning in practice, as reported by Christina Schimpe: WARNING: CPU: 5 PID: 1773 at arch/x86/kernel/fpu/regset.c:198 ssp_get+0x89/0xa0 [...] Call Trace: <TASK> ? show_regs+0x6e/0x80 ? ssp_get+0x89/0xa0 ? __warn+0x91/0x150 ? ssp_get+0x89/0xa0 ? report_bug+0x19d/0x1b0 ? handle_bug+0x46/0x80 ? exc_invalid_op+0x1d/0x80 ? asm_exc_invalid_op+0x1f/0x30 ? __pfx_ssp_get+0x10/0x10 ? ssp_get+0x89/0xa0 ? ssp_get+0x52/0xa0 __regset_get+0xad/0xf0 copy_regset_to_user+0x52/0xc0 ptrace_regset+0x119/0x140 ptrace_request+0x13c/0x850 ? wait_task_inactive+0x142/0x1d0 ? do_syscall_64+0x6d/0x90 arch_ptrace+0x102/0x300 [...] Ensure that shadow stacks are active in a thread before looking them up in the XSAVE buffer. Since ARCH_SHSTK_SHSTK and user_ssp[SHSTK_EN] are set at the same time, the active check ensures that there will be something to find in the XSAVE buffer. [ dhansen: changelog/subject tweaks ]
02 / AFFECTED SOFTWARE
Affected packages
2 explicit affected versions
16 explicit affected versions
29 explicit affected versions
10 explicit affected versions
11 explicit affected versions
21 explicit affected versions
9 explicit affected versions
1 explicit affected versions
22 explicit affected versions
2 explicit affected versions
7 explicit affected versions
26 explicit affected versions
37 explicit affected versions
10 explicit affected versions
10 explicit affected versions
13 explicit affected versions
13 explicit affected versions
78 explicit affected versions
45 explicit affected versions
37 explicit affected versions
8 explicit affected versions
4 explicit affected versions
8 explicit affected versions
19 explicit affected versions
23 explicit affected versions
23 explicit affected versions
7 explicit affected versions
10 explicit affected versions
33 explicit affected versions
16 explicit affected versions
13 explicit affected versions
2 explicit affected versions
12 explicit affected versions
38 explicit affected versions
16 explicit affected versions
1 explicit affected versions
51 explicit affected versions
13 explicit affected versions
10 explicit affected versions
13 explicit affected versions
17 explicit affected versions
10 explicit affected versions
24 explicit affected versions
13 explicit affected versions
10 explicit affected versions
23 explicit affected versions
1 explicit affected versions
10 explicit affected versions
10 explicit affected versions
1 explicit affected versions
20 explicit affected versions
8 explicit affected versions
1 explicit affected versions
13 explicit affected versions
21 explicit affected versions
6 explicit affected versions
13 explicit affected versions
12 explicit affected versions
23 explicit affected versions
14 explicit affected versions
7 explicit affected versions
14 explicit affected versions
18 explicit affected versions
21 explicit affected versions
12 explicit affected versions
26 explicit affected versions
1 explicit affected versions
18 explicit affected versions
2 explicit affected versions
20 explicit affected versions
22 explicit affected versions
15 explicit affected versions
23 explicit affected versions
14 explicit affected versions
5 explicit affected versions
3 explicit affected versions
23 explicit affected versions
26 explicit affected versions
12 explicit affected versions
44 explicit affected versions
4 explicit affected versions
4 explicit affected versions
16 explicit affected versions
9 explicit affected versions
12 explicit affected versions
7 explicit affected versions
13 explicit affected versions
7 explicit affected versions
13 explicit affected versions
7 explicit affected versions
10 explicit affected versions
14 explicit affected versions
26 explicit affected versions
18 explicit affected versions
3 explicit affected versions
16 explicit affected versions
43 explicit affected versions
19 explicit affected versions
28 explicit affected versions
18 explicit affected versions
11 explicit affected versions
35 explicit affected versions
27 explicit affected versions
12 explicit affected versions
13 explicit affected versions
17 explicit affected versions
6 explicit affected versions
12 explicit affected versions
1 explicit affected versions
50 explicit affected versions
11 explicit affected versions
12 explicit affected versions
27 explicit affected versions
12 explicit affected versions
7 explicit affected versions
03 / CONNECTIONS
Connected vulnerabilities
04 / EVIDENCE
Source records
In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Ensure shadow stack is active before "getting" registers The x86 shadow stack support has its own set of registers. Those registers are XSAVE-managed, but they are "supervisor state components" which means that userspace can not touch them with XSAVE/XRSTOR. It also means that they are not accessible from the existing ptrace ABI for XSAVE state. Thus, there is a new ptrace get/set interface for it. The regset code that ptrace uses provides an ->active() handler in addition to the get/set ones. For shadow stack this ->active() handler verifies that shadow stack is enabled via the ARCH_SHSTK_SHSTK bit in the thread struct. The ->active() handler is checked from some call sites of the regset get/set handlers, but not the ptrace ones. This was not understood when shadow stack support was put in place. As a result, both the set/get handlers can be called with XFEATURE_CET_USER in its init state, which would cause get_xsave_addr() to return NULL and trigger a WARN_ON(). The ssp_set() handler luckily has an ssp_active() check to avoid surprising the kernel with shadow stack behavior when the kernel is not ready for it (ARCH_SHSTK_SHSTK==0). That check just happened to avoid the warning. But the ->get() side wasn't so lucky. It can be called with shadow stacks disabled, triggering the warning in practice, as reported by Christina Schimpe: WARNING: CPU: 5 PID: 1773 at arch/x86/kernel/fpu/regset.c:198 ssp_get+0x89/0xa0 [...] Call Trace: <TASK> ? show_regs+0x6e/0x80 ? ssp_get+0x89/0xa0 ? __warn+0x91/0x150 ? ssp_get+0x89/0xa0 ? report_bug+0x19d/0x1b0 ? handle_bug+0x46/0x80 ? exc_invalid_op+0x1d/0x80 ? asm_exc_invalid_op+0x1f/0x30 ? __pfx_ssp_get+0x10/0x10 ? ssp_get+0x89/0xa0 ? ssp_get+0x52/0xa0 __regset_get+0xad/0xf0 copy_regset_to_user+0x52/0xc0 ptrace_regset+0x119/0x140 ptrace_request+0x13c/0x850 ? wait_task_inactive+0x142/0x1d0 ? do_syscall_64+0x6d/0x90 arch_ptrace+0x102/0x300 [...] Ensure that shadow stacks are active in a thread before looking them up in the XSAVE buffer. Since ARCH_SHSTK_SHSTK and user_ssp[SHSTK_EN] are set at the same time, the active check ensures that there will be something to find in the XSAVE buffer. [ dhansen: changelog/subject tweaks ]
05 / REFERENCES
Further evidence
- https://git.kernel.org/linus/a9d9c33132d49329ada647e4514d210d15e31d81
- https://git.kernel.org/stable/c/0a3a872214188e4268d31581ed0cd44508e038cf
- https://git.kernel.org/stable/c/6bfe1fc22f462bec87422cdcbec4d7a2f43ff01d
- https://git.kernel.org/stable/c/a9d9c33132d49329ada647e4514d210d15e31d81
- https://ubuntu.com/security/CVE-2025-21632
- https://ubuntu.com/security/notices/USN-7379-1
- https://ubuntu.com/security/notices/USN-7379-2
- https://ubuntu.com/security/notices/USN-7380-1
- https://ubuntu.com/security/notices/USN-7381-1
- https://ubuntu.com/security/notices/USN-7382-1
- https://ubuntu.com/security/notices/USN-7513-1
- https://ubuntu.com/security/notices/USN-7513-2
- https://ubuntu.com/security/notices/USN-7513-3
- https://ubuntu.com/security/notices/USN-7513-4
- https://ubuntu.com/security/notices/USN-7513-5
- https://ubuntu.com/security/notices/USN-7514-1
- https://ubuntu.com/security/notices/USN-7515-1
- https://ubuntu.com/security/notices/USN-7515-2
- https://ubuntu.com/security/notices/USN-7522-1
- https://ubuntu.com/security/notices/USN-7523-1
- https://ubuntu.com/security/notices/USN-7524-1
- https://www.cve.org/CVERecord?id=CVE-2025-21632