CVE-2022-49783
MediumIn 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. ]
CVSS 3.1 score
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Affected versions
Linux kernel versions
5.16
and later are affected. Fixed in
6.0.10,
6.1
and their respective stable series.
References
The following references provide additional information about CVE-2022-49783 including vendor advisories, patch commits, exploit details, and third-party analysis. Links are sourced from the NIST NVD database.
-
PatchKernel patch commithttps://git.kernel.org/stable/c/36b038791e1e2baea892e9276588815fd14894b4
-
PatchKernel patch commithttps://git.kernel.org/stable/c/c6e8a7a1780af3da65e78a615f7d0874da6aabb0
Frequently asked questions
-
What is CVE-2022-49783?
CVE-2022-49783 is a Medium severity Linux kernel vulnerability with a CVSS score of 5.5 out of 10 . It affects Linux kernel versions from 5.16 onward and has been patched in 6.0.10 and 6.1. CVE-2022-49783 has not been confirmed as actively exploited and is not listed in the CISA KEV catalog.
-
What is the CVSS score for CVE-2022-49783?
CVE-2022-49783 has a CVSS score of 5.5 out of 10, rated Medium severity (CVSS 3.1). The vector string is
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H. -
Is there a patch available for CVE-2022-49783?
Yes — CVE-2022-49783 has been patched. Fixed versions include 6.0.10 and 6.1. If you are running Linux kernel 5.16 or later up to the fix versions, apply the relevant patch for your kernel branch.
-
Is CVE-2022-49783 actively exploited?
No — CVE-2022-49783 has not been confirmed as actively exploited. It is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.