Linux Kernel up to 6.6.71/6.12.9/6.13-rc6 fpu buffer overflow

Summaryinfo

A vulnerability has been found in Linux Kernel up to 6.6.71/6.12.9/6.13-rc6 and classified as critical. Impacted is an unknown function of the component fpu. This manipulation causes buffer overflow. This vulnerability is handled as CVE-2025-21632. There is not any exploit available. The affected component should be upgraded.

Detailsinfo

A vulnerability was found in Linux Kernel up to 6.6.71/6.12.9/6.13-rc6. It has been declared as critical. Affected by this vulnerability is an unknown part of the component fpu. The manipulation with an unknown input leads to a buffer overflow vulnerability. The CWE definition for the vulnerability is CWE-120. The product copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow. As an impact it is known to affect confidentiality, integrity, and availability. The summary by CVE is:

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: ? 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 ]

The advisory is shared at git.kernel.org. This vulnerability is known as CVE-2025-21632 since 12/29/2024. The exploitation appears to be easy. Neither technical details nor an exploit are publicly available. The price for an exploit might be around USD $0-$5k at the moment (estimation calculated on 02/17/2026).

The vulnerability scanner Nessus provides a plugin with the ID 214901 (SUSE SLES15 Security Update : kernel (SUSE-SU-2025:0289-1)), which helps to determine the existence of the flaw in a target environment.

Upgrading to version 6.6.72, 6.12.10 or 6.13-rc7 eliminates this vulnerability. Applying the patch 0a3a872214188e4268d31581ed0cd44508e038cf/6bfe1fc22f462bec87422cdcbec4d7a2f43ff01d/a9d9c33132d49329ada647e4514d210d15e31d81 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

The vulnerability is also documented in the databases at Tenable (214901) and CERT Bund (WID-SEC-2025-0119). Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Affected

• Debian Linux
• Amazon Linux 2
• Red Hat Enterprise Linux
• Ubuntu Linux
• SUSE Linux
• Oracle Linux
• RESF Rocky Linux
• Dell NetWorker
• Dell Avamar
• Dell PowerProtect Data Domain
• Open Source Linux Kernel
• Dell Secure Connect Gateway

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 6.6.0
• 6.6.1
• 6.6.2
• 6.6.3
• 6.6.4
• 6.6.5
• 6.6.6
• 6.6.7
• 6.6.8
• 6.6.9
• 6.6.10
• 6.6.11
• 6.6.12
• 6.6.13
• 6.6.14
• 6.6.15
• 6.6.16
• 6.6.17
• 6.6.18
• 6.6.19
• 6.6.20
• 6.6.21
• 6.6.22
• 6.6.23
• 6.6.24
• 6.6.25
• 6.6.26
• 6.6.27
• 6.6.28
• 6.6.29
• 6.6.30
• 6.6.31
• 6.6.32
• 6.6.33
• 6.6.34
• 6.6.35
• 6.6.36
• 6.6.37
• 6.6.38
• 6.6.39
• 6.6.40
• 6.6.41
• 6.6.42
• 6.6.43
• 6.6.44
• 6.6.45
• 6.6.46
• 6.6.47
• 6.6.48
• 6.6.49
• 6.6.50
• 6.6.51
• 6.6.52
• 6.6.53
• 6.6.54
• 6.6.55
• 6.6.56
• 6.6.57
• 6.6.58
• 6.6.59
• 6.6.60
• 6.6.61
• 6.6.62
• 6.6.63
• 6.6.64
• 6.6.65
• 6.6.66
• 6.6.67
• 6.6.68
• 6.6.69
• 6.6.70
• 6.6.71
• 6.12.0
• 6.12.1
• 6.12.2
• 6.12.3
• 6.12.4
• 6.12.5
• 6.12.6
• 6.12.7
• 6.12.8
• 6.12.9
• 6.13-rc1
• 6.13-rc2
• 6.13-rc3
• 6.13-rc4
• 6.13-rc5
• 6.13-rc6

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔍
• 🔍
• 🔍

CPE 2.2info

• 🔍
• 🔍
• 🔍

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Discussion