fkie_cve-2022-49783
Vulnerability from fkie_nvd
Published
2025-05-01 15:16
Modified
2025-11-07 17:48
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved:
x86/fpu: Drop fpregs lock before inheriting FPU permissions
Mike Galbraith reported the following against an old fork of preempt-rt
but the same issue also applies to the current preempt-rt tree.
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: systemd
preempt_count: 1, expected: 0
RCU nest depth: 0, expected: 0
Preemption disabled at:
fpu_clone
CPU: 6 PID: 1 Comm: systemd Tainted: G E (unreleased)
Call Trace:
<TASK>
dump_stack_lvl
? fpu_clone
__might_resched
rt_spin_lock
fpu_clone
? copy_thread
? copy_process
? shmem_alloc_inode
? kmem_cache_alloc
? kernel_clone
? __do_sys_clone
? do_syscall_64
? __x64_sys_rt_sigprocmask
? syscall_exit_to_user_mode
? do_syscall_64
? syscall_exit_to_user_mode
? do_syscall_64
? syscall_exit_to_user_mode
? do_syscall_64
? exc_page_fault
? entry_SYSCALL_64_after_hwframe
</TASK>
Mike says:
The splat comes from fpu_inherit_perms() being called under fpregs_lock(),
and us reaching the spin_lock_irq() therein due to fpu_state_size_dynamic()
returning true despite static key __fpu_state_size_dynamic having never
been enabled.
Mike's assessment looks correct. fpregs_lock on a PREEMPT_RT kernel disables
preemption so calling spin_lock_irq() in fpu_inherit_perms() is unsafe. This
problem exists since commit
9e798e9aa14c ("x86/fpu: Prepare fpu_clone() for dynamically enabled features").
Even though the original bug report should not have enabled the paths at
all, the bug still exists.
fpregs_lock is necessary when editing the FPU registers or a task's FP
state but it is not necessary for fpu_inherit_perms(). The only write
of any FP state in fpu_inherit_perms() is for the new child which is
not running yet and cannot context switch or be borrowed by a kernel
thread yet. Hence, fpregs_lock is not protecting anything in the new
child until clone() completes and can be dropped earlier. The siglock
still needs to be acquired by fpu_inherit_perms() as the read of the
parent's permissions has to be serialised.
[ bp: Cleanup splat. ]
References
Impacted products
| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | 6.1 | |
| linux | linux_kernel | 6.1 | |
| linux | linux_kernel | 6.1 | |
| linux | linux_kernel | 6.1 | |
| linux | linux_kernel | 6.1 |
{
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "64F9ADD1-3ADB-4D66-A00F-4A83010B05F0",
"versionEndExcluding": "6.0.10",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.1:rc1:*:*:*:*:*:*",
"matchCriteriaId": "E7E331DA-1FB0-4DEC-91AC-7DA69D461C11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.1:rc2:*:*:*:*:*:*",
"matchCriteriaId": "17F0B248-42CF-4AE6-A469-BB1BAE7F4705",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.1:rc3:*:*:*:*:*:*",
"matchCriteriaId": "E2422816-0C14-4B5E-A1E6-A9D776E5C49B",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.1:rc4:*:*:*:*:*:*",
"matchCriteriaId": "1C6E00FE-5FB9-4D20-A1A1-5A32128F9B76",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.1:rc5:*:*:*:*:*:*",
"matchCriteriaId": "35B26BE4-43A6-4A36-A7F6-5B3F572D9186",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/fpu: Drop fpregs lock before inheriting FPU permissions\n\nMike Galbraith reported the following against an old fork of preempt-rt\nbut the same issue also applies to the current preempt-rt tree.\n\n BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46\n in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: systemd\n preempt_count: 1, expected: 0\n RCU nest depth: 0, expected: 0\n Preemption disabled at:\n fpu_clone\n CPU: 6 PID: 1 Comm: systemd Tainted: G E (unreleased)\n Call Trace:\n \u003cTASK\u003e\n dump_stack_lvl\n ? fpu_clone\n __might_resched\n rt_spin_lock\n fpu_clone\n ? copy_thread\n ? copy_process\n ? shmem_alloc_inode\n ? kmem_cache_alloc\n ? kernel_clone\n ? __do_sys_clone\n ? do_syscall_64\n ? __x64_sys_rt_sigprocmask\n ? syscall_exit_to_user_mode\n ? do_syscall_64\n ? syscall_exit_to_user_mode\n ? do_syscall_64\n ? syscall_exit_to_user_mode\n ? do_syscall_64\n ? exc_page_fault\n ? entry_SYSCALL_64_after_hwframe\n \u003c/TASK\u003e\n\nMike says:\n\n The splat comes from fpu_inherit_perms() being called under fpregs_lock(),\n and us reaching the spin_lock_irq() therein due to fpu_state_size_dynamic()\n returning true despite static key __fpu_state_size_dynamic having never\n been enabled.\n\nMike\u0027s assessment looks correct. fpregs_lock on a PREEMPT_RT kernel disables\npreemption so calling spin_lock_irq() in fpu_inherit_perms() is unsafe. This\nproblem exists since commit\n\n 9e798e9aa14c (\"x86/fpu: Prepare fpu_clone() for dynamically enabled features\").\n\nEven though the original bug report should not have enabled the paths at\nall, the bug still exists.\n\nfpregs_lock is necessary when editing the FPU registers or a task\u0027s FP\nstate but it is not necessary for fpu_inherit_perms(). The only write\nof any FP state in fpu_inherit_perms() is for the new child which is\nnot running yet and cannot context switch or be borrowed by a kernel\nthread yet. Hence, fpregs_lock is not protecting anything in the new\nchild until clone() completes and can be dropped earlier. The siglock\nstill needs to be acquired by fpu_inherit_perms() as the read of the\nparent\u0027s permissions has to be serialised.\n\n [ bp: Cleanup splat. ]"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/fpu: Eliminar el bloqueo de fpregs antes de heredar los permisos de FPU Mike Galbraith inform\u00f3 lo siguiente contra una antigua bifurcaci\u00f3n de preempt-rt, pero el mismo problema tambi\u00e9n se aplica al \u00e1rbol preempt-rt actual. ERROR: funci\u00f3n inactiva llamada desde un contexto no v\u00e1lido en kernel/locking/spinlock_rt.c:46 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: systemd preempt_count: 1, expected: 0 Profundidad de anidamiento de RCU: 0, expected: 0 Preempci\u00f3n deshabilitada en: fpu_clone CPU: 6 PID: 1 Comm: systemd Tainted: GE (no publicado) Rastreo de llamadas: dump_stack_lvl ? fpu_clone __might_resched rt_spin_lock fpu_clone ? copy_thread ? copy_process ? shmem_alloc_inode ? kmem_cache_alloc ? kernel_clone ? __do_sys_clone ? do_syscall_64 ? __x64_sys_rt_sigprocmask ? syscall_exit_to_user_mode ? do_syscall_64 ? syscall_exit_to_user_mode ? do_syscall_64 ? syscall_exit_to_user_mode ? do_syscall_64 ? exc_page_fault ? entry_SYSCALL_64_after_hwframe Mike dice: El problema se debe a que fpu_inherit_perms() se llama bajo fpregs_lock() y a que alcanzamos spin_lock_irq() debido a que fpu_state_size_dynamic() devuelve verdadero a pesar de que la clave est\u00e1tica __fpu_state_size_dynamic nunca se ha habilitado. La evaluaci\u00f3n de Mike parece correcta. fpregs_lock en un kernel PREEMPT_RT deshabilita la preempci\u00f3n, por lo que llamar a spin_lock_irq() en fpu_inherit_perms() no es seguro. Este problema existe desde la confirmaci\u00f3n 9e798e9aa14c (\"x86/fpu: Preparar fpu_clone() para funciones habilitadas din\u00e1micamente\"). Aunque el informe de error original no deber\u00eda haber habilitado las rutas, el error persiste. fpregs_lock es necesario al editar los registros de FPU o el estado de FP de una tarea, pero no es necesario para fpu_inherit_perms(). La \u00fanica escritura de cualquier estado de FP en fpu_inherit_perms() es para el nuevo hijo, que a\u00fan no se est\u00e1 ejecutando y a\u00fan no puede cambiar de contexto ni ser tomado prestado por un hilo del kernel. Por lo tanto, fpregs_lock no protege nada en el nuevo hijo hasta que clone() se complete y pueda eliminarse antes. El siglock a\u00fan debe ser adquirido por fpu_inherit_perms(), ya que la lectura de los permisos del padre debe serializarse. [bp: Limpieza splat.]"
}
],
"id": "CVE-2022-49783",
"lastModified": "2025-11-07T17:48:52.480",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "nvd@nist.gov",
"type": "Primary"
}
]
},
"published": "2025-05-01T15:16:01.510",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/36b038791e1e2baea892e9276588815fd14894b4"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/c6e8a7a1780af3da65e78a615f7d0874da6aabb0"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Analyzed",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "NVD-CWE-noinfo"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
Loading…
Loading…
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.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- 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.
Loading…
Loading…