CVE-2026-23102

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64/fpsimd: signal: Fix restoration of SVE context<br /> <br /> When SME is supported, Restoring SVE signal context can go wrong in a<br /> few ways, including placing the task into an invalid state where the<br /> kernel may read from out-of-bounds memory (and may potentially take a<br /> fatal fault) and/or may kill the task with a SIGKILL.<br /> <br /> (1) Restoring a context with SVE_SIG_FLAG_SM set can place the task into<br /> an invalid state where SVCR.SM is set (and sve_state is non-NULL)<br /> but TIF_SME is clear, consequently resuting in out-of-bounds memory<br /> reads and/or killing the task with SIGKILL.<br /> <br /> This can only occur in unusual (but legitimate) cases where the SVE<br /> signal context has either been modified by userspace or was saved in<br /> the context of another task (e.g. as with CRIU), as otherwise the<br /> presence of an SVE signal context with SVE_SIG_FLAG_SM implies that<br /> TIF_SME is already set.<br /> <br /> While in this state, task_fpsimd_load() will NOT configure SMCR_ELx<br /> (leaving some arbitrary value configured in hardware) before<br /> restoring SVCR and attempting to restore the streaming mode SVE<br /> registers from memory via sve_load_state(). As the value of<br /> SMCR_ELx.LEN may be larger than the task&amp;#39;s streaming SVE vector<br /> length, this may read memory outside of the task&amp;#39;s allocated<br /> sve_state, reading unrelated data and/or triggering a fault.<br /> <br /> While this can result in secrets being loaded into streaming SVE<br /> registers, these values are never exposed. As TIF_SME is clear,<br /> fpsimd_bind_task_to_cpu() will configure CPACR_ELx.SMEN to trap EL0<br /> accesses to streaming mode SVE registers, so these cannot be<br /> accessed directly at EL0. As fpsimd_save_user_state() verifies the<br /> live vector length before saving (S)SVE state to memory, no secret<br /> values can be saved back to memory (and hence cannot be observed via<br /> ptrace, signals, etc).<br /> <br /> When the live vector length doesn&amp;#39;t match the expected vector length<br /> for the task, fpsimd_save_user_state() will send a fatal SIGKILL<br /> signal to the task. Hence the task may be killed after executing<br /> userspace for some period of time.<br /> <br /> (2) Restoring a context with SVE_SIG_FLAG_SM clear does not clear the<br /> task&amp;#39;s SVCR.SM. If SVCR.SM was set prior to restoring the context,<br /> then the task will be left in streaming mode unexpectedly, and some<br /> register state will be combined inconsistently, though the task will<br /> be left in legitimate state from the kernel&amp;#39;s PoV.<br /> <br /> This can only occur in unusual (but legitimate) cases where ptrace<br /> has been used to set SVCR.SM after entry to the sigreturn syscall,<br /> as syscall entry clears SVCR.SM.<br /> <br /> In these cases, the the provided SVE register data will be loaded<br /> into the task&amp;#39;s sve_state using the non-streaming SVE vector length<br /> and the FPSIMD registers will be merged into this using the<br /> streaming SVE vector length.<br /> <br /> Fix (1) by setting TIF_SME when setting SVCR.SM. This also requires<br /> ensuring that the task&amp;#39;s sme_state has been allocated, but as this could<br /> contain live ZA state, it should not be zeroed. Fix (2) by clearing<br /> SVCR.SM when restoring a SVE signal context with SVE_SIG_FLAG_SM clear.<br /> <br /> For consistency, I&amp;#39;ve pulled the manipulation of SVCR, TIF_SVE, TIF_SME,<br /> and fp_type earlier, immediately after the allocation of<br /> sve_state/sme_state, before the restore of the actual register state.<br /> This makes it easier to ensure that these are always modified<br /> consistently, even if a fault is taken while reading the register data<br /> from the signal context. I do not expect any software to depend on the<br /> exact state restored when a fault is taken while reading the context.