Entreprise française de cybersécurité depuis 2004
☎ 03 60 47 09 81 - info@securiteinfo.com
☎ 03 60 47 09 81 - info@securiteinfo.com
In the Linux kernel, the following vulnerability has been resolved:x86/fpu: Ensure shadow stack is active before "getting" registersThe x86 shadow stack support has its own set of registers. Those registersare XSAVE-managed, but they are "supervisor state components" which meansthat userspace can not touch them with XSAVE/XRSTOR. It also means thatthey 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 inaddition to the get/set ones. For shadow stack this ->active() handlerverifies that shadow stack is enabled via the ARCH_SHSTK_SHSTK bit in thethread struct. The ->active() handler is checked from some call sites ofthe regset get/set handlers, but not the ptrace ones. This was notunderstood when shadow stack support was put in place.As a result, both the set/get handlers can be called withXFEATURE_CET_USER in its init state, which would cause get_xsave_addr() toreturn NULL and trigger a WARN_ON(). The ssp_set() handler luckily has anssp_active() check to avoid surprising the kernel with shadow stackbehavior when the kernel is not ready for it (ARCH_SHSTK_SHSTK==0). Thatcheck just happened to avoid the warning.But the ->get() side wasn't so lucky. It can be called with shadow stacksdisabled, triggering the warning in practice, as reported by ChristinaSchimpe:WARNING: CPU: 5 PID: 1773 at arch/x86/kernel/fpu/regset.c:198 ssp_get+0x89/0xa0[...]Call Trace:
No PoCs from references.
- https://github.com/fkie-cad/nvd-json-data-feeds
- https://github.com/oogasawa/Utility-security