В ядре Linux устранена следующая уязвимость:
Arm64/fpsimd: signal: исправить восстановление контекста SVE. Если поддерживается SME, восстановление контекста сигнала SVE может пойти не так, как надо.
несколькими способами, включая перевод задачи в недопустимое состояние, когда
ядро может читать из внешней памяти (и потенциально может занять
фатальная ошибка) и/или может завершить задачу с помощью SIGKILL.
(1) Восстановление контекста с установленным SVE_SIG_FLAG_SM может поместить задачу в
недопустимое состояние, в котором установлен SVCR.SM (и sve_state не равно NULL)
но TIF_SME чист, что приводит к выходу за пределы памяти
читает и/или уничтожает задачу с помощью SIGKILL. Это может произойти только в необычных (но законных) случаях, когда SVE
Контекст сигнала либо был изменен пользовательским пространством, либо был сохранен в
контекст другой задачи (например, как в случае с CRIU), иначе
наличие контекста сигнала SVE с SVE_SIG_FLAG_SM подразумевает, что
TIF_SME уже установлен.
В этом состоянии Task_fpsimd_load() НЕ будет настраивать SMCR_ELx.
(оставляя произвольное значение, настроенное аппаратно) перед
восстановление SVCR и попытка восстановления потокового режима SVE
регистрируется из памяти через sve_load_state(). Поскольку значение
SMCR_ELx.LEN может быть больше вектора потоковой передачи SVE задачи.
длина, это может прочитать память за пределами выделенной задаче
sve_state, чтение несвязанных данных и/или срабатывание ошибки. Хотя это может привести к загрузке секретов в потоковую передачу SVE.
регистры, эти значения никогда не раскрываются.
Поскольку TIF_SME ясно,
fpsimd_bind_task_to_cpu() настроит CPACR_ELx.SMEN для перехвата EL0
доступ к регистрам SVE потокового режима, поэтому они не могут быть
доступ осуществляется непосредственно через EL0. Поскольку fpsimd_save_user_state() проверяет
длина живого вектора перед сохранением состояния (S)SVE в памяти, не секрет
значения могут быть сохранены обратно в память (и, следовательно, их нельзя наблюдать через
ptrace, сигналы и т. д.). Когда длина живого вектора не соответствует ожидаемой длине вектора
для этой задачи fpsimd_save_user_state() отправит фатальный SIGKILL
сигнал к задаче.
Следовательно, задача может быть уничтожена после выполнения
пользовательское пространство в течение некоторого периода времени.
(2) Восстановление контекста с помощью очистки SVE_SIG_FLAG_SM не очищает
SVCR.SM задачи. Если SVCR.SM был установлен до восстановления контекста,
то задача неожиданно останется в потоковом режиме, и некоторые
состояние регистра будет объединено непоследовательно, хотя задача будет
оставаться в легитимном состоянии с точки зрения PoV ядра. Это может произойти только в необычных (но законных) случаях, когда ptrace
использовался для установки SVCR.SM после входа в системный вызов sigreturn,
поскольку запись системного вызова очищает SVCR.SM.
В этих случаях будут загружены предоставленные данные регистра SVE.
в sve_state задачи, используя длину непотокового вектора SVE
и регистры FPSIMD будут объединены с ним с помощью
Длина потокового вектора SVE. Исправьте (1), установив TIF_SME при настройке SVCR.SM. Это также требует
гарантируя, что sme_state задачи был выделен, но поскольку это может
содержат активное состояние ZA, его не следует обнулять.
Исправьте (2), очистив
SVCR.SM при восстановлении контекста сигнала SVE с очисткой SVE_SIG_FLAG_SM. Для единообразия я убрал манипуляции с SVCR, TIF_SVE, TIF_SME,
и fp_type раньше, сразу после выделения
sve_state/sme_state, перед восстановлением фактического состояния регистра. Это облегчает обеспечение того, чтобы они всегда изменялись.
последовательно, даже если при чтении данных регистра возникает ошибка
из контекста сигнала.
Я не ожидаю, что какое-либо программное обеспечение будет зависеть от точное состояние восстанавливается при возникновении ошибки при чтении контекста.
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: arm64/fpsimd: signal: Fix restoration of SVE context When SME is supported, Restoring SVE signal context can go wrong in a few ways, including placing the task into an invalid state where the kernel may read from out-of-bounds memory (and may potentially take a fatal fault) and/or may kill the task with a SIGKILL. (1) Restoring a context with SVE_SIG_FLAG_SM set can place the task into an invalid state where SVCR.SM is set (and sve_state is non-NULL) but TIF_SME is clear, consequently resuting in out-of-bounds memory reads and/or killing the task with SIGKILL. This can only occur in unusual (but legitimate) cases where the SVE signal context has either been modified by userspace or was saved in the context of another task (e.g. as with CRIU), as otherwise the presence of an SVE signal context with SVE_SIG_FLAG_SM implies that TIF_SME is already set. While in this state, task_fpsimd_load() will NOT configure SMCR_ELx (leaving some arbitrary value configured in hardware) before restoring SVCR and attempting to restore the streaming mode SVE registers from memory via sve_load_state(). As the value of SMCR_ELx.LEN may be larger than the task's streaming SVE vector length, this may read memory outside of the task's allocated sve_state, reading unrelated data and/or triggering a fault. While this can result in secrets being loaded into streaming SVE registers, these values are never exposed. As TIF_SME is clear, fpsimd_bind_task_to_cpu() will configure CPACR_ELx.SMEN to trap EL0 accesses to streaming mode SVE registers, so these cannot be accessed directly at EL0. As fpsimd_save_user_state() verifies the live vector length before saving (S)SVE state to memory, no secret values can be saved back to memory (and hence cannot be observed via ptrace, signals, etc). When the live vector length doesn't match the expected vector length for the task, fpsimd_save_user_state() will send a fatal SIGKILL signal to the task. Hence the task may be killed after executing userspace for some period of time. (2) Restoring a context with SVE_SIG_FLAG_SM clear does not clear the task's SVCR.SM. If SVCR.SM was set prior to restoring the context, then the task will be left in streaming mode unexpectedly, and some register state will be combined inconsistently, though the task will be left in legitimate state from the kernel's PoV. This can only occur in unusual (but legitimate) cases where ptrace has been used to set SVCR.SM after entry to the sigreturn syscall, as syscall entry clears SVCR.SM. In these cases, the the provided SVE register data will be loaded into the task's sve_state using the non-streaming SVE vector length and the FPSIMD registers will be merged into this using the streaming SVE vector length. Fix (1) by setting TIF_SME when setting SVCR.SM. This also requires ensuring that the task's sme_state has been allocated, but as this could contain live ZA state, it should not be zeroed. Fix (2) by clearing SVCR.SM when restoring a SVE signal context with SVE_SIG_FLAG_SM clear. For consistency, I've pulled the manipulation of SVCR, TIF_SVE, TIF_SME, and fp_type earlier, immediately after the allocation of sve_state/sme_state, before the restore of the actual register state. This makes it easier to ensure that these are always modified consistently, even if a fault is taken while reading the register data from the signal context. I do not expect any software to depend on the exact state restored when a fault is taken while reading the context.