ghsa-4grr-9vhg-g98w
Vulnerability from github
In the Linux kernel, the following vulnerability has been resolved:
arm64/sve: Discard stale CPU state when handling SVE traps
The logic for handling SVE traps manipulates saved FPSIMD/SVE state incorrectly, and a race with preemption can result in a task having TIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SVE traps enabled). This has been observed to result in warnings from do_sve_acc() where SVE traps are not expected while TIF_SVE is set:
| if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); / SVE access shouldn't have trapped /
Warnings of this form have been reported intermittently, e.g.
https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/ https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/
The race can occur when the SVE trap handler is preempted before and after manipulating the saved FPSIMD/SVE state, starting and ending on the same CPU, e.g.
| void do_sve_acc(unsigned long esr, struct pt_regs regs) | { | // Trap on CPU 0 with TIF_SVE clear, SVE traps enabled | // task->fpsimd_cpu is 0. | // per_cpu_ptr(&fpsimd_last_state, 0) is task. | | ... | | // Preempted; migrated from CPU 0 to CPU 1. | // TIF_FOREIGN_FPSTATE is set. | | get_cpu_fpsimd_context(); | | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); / SVE access shouldn't have trapped */ | | sve_init_regs() { | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { | ... | } else { | fpsimd_to_sve(current); | current->thread.fp_type = FP_STATE_SVE; | } | } | | put_cpu_fpsimd_context(); | | // Preempted; migrated from CPU 1 to CPU 0. | // task->fpsimd_cpu is still 0 | // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then: | // - Stale HW state is reused (with SVE traps enabled) | // - TIF_FOREIGN_FPSTATE is cleared | // - A return to userspace skips HW state restore | }
Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is set by calling fpsimd_flush_task_state() to detach from the saved CPU state. This ensures that a subsequent context switch will not reuse the stale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the new state to be reloaded from memory prior to a return to userspace.
{
"affected": [],
"aliases": [
"CVE-2024-50275"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-19T02:16:29Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\narm64/sve: Discard stale CPU state when handling SVE traps\n\nThe logic for handling SVE traps manipulates saved FPSIMD/SVE state\nincorrectly, and a race with preemption can result in a task having\nTIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU state\nis stale (e.g. with SVE traps enabled). This has been observed to result\nin warnings from do_sve_acc() where SVE traps are not expected while\nTIF_SVE is set:\n\n| if (test_and_set_thread_flag(TIF_SVE))\n| WARN_ON(1); /* SVE access shouldn\u0027t have trapped */\n\nWarnings of this form have been reported intermittently, e.g.\n\n https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/\n https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/\n\nThe race can occur when the SVE trap handler is preempted before and\nafter manipulating the saved FPSIMD/SVE state, starting and ending on\nthe same CPU, e.g.\n\n| void do_sve_acc(unsigned long esr, struct pt_regs *regs)\n| {\n| // Trap on CPU 0 with TIF_SVE clear, SVE traps enabled\n| // task-\u003efpsimd_cpu is 0.\n| // per_cpu_ptr(\u0026fpsimd_last_state, 0) is task.\n|\n| ...\n|\n| // Preempted; migrated from CPU 0 to CPU 1.\n| // TIF_FOREIGN_FPSTATE is set.\n|\n| get_cpu_fpsimd_context();\n|\n| if (test_and_set_thread_flag(TIF_SVE))\n| WARN_ON(1); /* SVE access shouldn\u0027t have trapped */\n|\n| sve_init_regs() {\n| if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) {\n| ...\n| } else {\n| fpsimd_to_sve(current);\n| current-\u003ethread.fp_type = FP_STATE_SVE;\n| }\n| }\n|\n| put_cpu_fpsimd_context();\n|\n| // Preempted; migrated from CPU 1 to CPU 0.\n| // task-\u003efpsimd_cpu is still 0\n| // If per_cpu_ptr(\u0026fpsimd_last_state, 0) is still task then:\n| // - Stale HW state is reused (with SVE traps enabled)\n| // - TIF_FOREIGN_FPSTATE is cleared\n| // - A return to userspace skips HW state restore\n| }\n\nFix the case where the state is not live and TIF_FOREIGN_FPSTATE is set\nby calling fpsimd_flush_task_state() to detach from the saved CPU\nstate. This ensures that a subsequent context switch will not reuse the\nstale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the\nnew state to be reloaded from memory prior to a return to userspace.",
"id": "GHSA-4grr-9vhg-g98w",
"modified": "2024-12-14T21:31:33Z",
"published": "2024-11-19T03:31:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50275"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/51d11ea0250d6ee461987403bbfd4b2abb5613a7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/51d3d80a6dc314982a9a0aeb0961085922a1aa15"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/751ecf6afd6568adc98f2a6052315552c0483d18"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/de529504b3274d57caf8f66800b714b0d3ee235a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fa9ce027b3ce37a2bb173bf2553b5caa438fd8c9"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.