CVE-2022-49783 in Linux
Summary
by MITRE • 05/01/2025
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. ]
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 02/03/2026
The vulnerability described in CVE-2022-49783 resides within the Linux kernel's x86 floating-point unit (FPU) subsystem, specifically affecting the preempt-rt real-time kernel configuration. This issue manifests as a deadlock condition occurring during the FPU permission inheritance process when cloning processes. The problem stems from improper locking mechanisms that create a scenario where a sleeping function attempts to acquire a spinlock from an invalid execution context, leading to system instability and potential denial of service conditions. The vulnerability impacts systems running real-time kernel variants where preemption is disabled, making it particularly dangerous in latency-sensitive environments.
The technical flaw occurs in the fpu_clone function where the fpregs_lock is held while calling fpu_inherit_perms, which subsequently attempts to acquire another spinlock through spin_lock_irq(). This creates a fundamental conflict because the fpregs_lock in PREEMPT_RT environments disables preemption, yet the code path attempts to acquire an interrupt-disabling lock, violating kernel locking semantics. The root cause lies in the dynamic FPU state size detection mechanism, where fpu_state_size_dynamic() returns true even when the static key __fpu_state_size_dynamic has never been enabled, triggering unsafe locking sequences. This issue has existed since commit 9e798e9aa14c, indicating it's not a recent regression but a longstanding design flaw in the FPU handling code.
The operational impact of this vulnerability extends beyond simple system instability to potentially compromise the entire real-time kernel functionality. When the system encounters this condition, it triggers a kernel oops with a BUG message indicating sleeping function called from invalid context, which can result in system crashes or forced reboots. This is particularly concerning for industrial control systems, automotive applications, and other real-time environments where system reliability and deterministic behavior are paramount. The vulnerability affects process creation operations, specifically those involving clone() system calls, making it exploitable through normal system operation or potentially through malicious process spawning attempts. The security implications include potential privilege escalation or denial of service attacks that could disrupt critical real-time operations.
The mitigation strategy involves restructuring the FPU permission inheritance logic to drop the fpregs_lock earlier in the process before calling fpu_inherit_perms, since the lock is not actually protecting the operations performed in the inheritance function. The fix requires that the function acquire the siglock for serializing access to parent FPU permissions while avoiding the problematic spin_lock_irq() call that occurs within the current implementation. This approach aligns with the ATT&CK framework's privilege escalation techniques by addressing the underlying kernel vulnerability that could be leveraged to gain unauthorized system access. The solution follows CWE-362 principles for concurrent execution management, ensuring that locking mechanisms don't create deadlock conditions. Organizations should prioritize applying the kernel patches that implement this fix, particularly in production systems running real-time kernel configurations where the risk of encountering this race condition is significantly higher due to the nature of real-time scheduling and preemption handling.