CVE-2022-49990 in Linux
Summary
by MITRE • 06/18/2025
In the Linux kernel, the following vulnerability has been resolved:
s390: fix double free of GS and RI CBs on fork() failure
The pointers for guarded storage and runtime instrumentation control blocks are stored in the thread_struct of the associated task. These pointers are initially copied on fork() via arch_dup_task_struct() and then cleared via copy_thread() before fork() returns. If fork() happens to fail after the initial task dup and before copy_thread(), the newly allocated task and associated thread_struct memory are freed via free_task() -> arch_release_task_struct(). This results in a double free of the guarded storage and runtime info structs because the fields in the failed task still refer to memory associated with the source task.
This problem can manifest as a BUG_ON() in set_freepointer() (with CONFIG_SLAB_FREELIST_HARDENED enabled) or KASAN splat (if enabled) when running trinity syscall fuzz tests on s390x. To avoid this problem, clear the associated pointer fields in arch_dup_task_struct() immediately after the new task is copied. Note that the RI flag is still cleared in copy_thread() because it resides in thread stack memory and that is where stack info is copied.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 11/30/2025
The vulnerability described in CVE-2022-49990 represents a critical double free condition affecting the Linux kernel's s390 architecture implementation. This flaw occurs within the process forking mechanism where guarded storage and runtime instrumentation control blocks are improperly managed during fork() failure scenarios. The issue specifically impacts the s390x architecture and demonstrates how memory management inconsistencies can lead to system instability and potential exploitation vectors. The vulnerability stems from improper pointer handling during the task duplication process, creating a scenario where the same memory regions are freed twice, leading to undefined behavior and system crashes.
The technical root cause lies in the sequence of operations during fork() execution where memory management functions are called in an incorrect order. The thread_struct of tasks contains pointers to guarded storage and runtime instrumentation control blocks that are initially duplicated during arch_dup_task_struct() execution. These pointers are subsequently cleared by copy_thread() before fork() returns to the caller. However, when fork() fails after the initial task duplication but before copy_thread() completes, the system calls free_task() which in turn invokes arch_release_task_struct(). This sequence results in the same memory regions being freed twice because the failed task's thread_struct still maintains references to memory that belongs to the source task. The problem manifests as either a BUG_ON() failure when CONFIG_SLAB_FREELIST_HARDENED is enabled or generates KASAN splats during trinity syscall fuzz testing, indicating memory corruption issues.
The operational impact of this vulnerability extends beyond simple system crashes to potentially enable more sophisticated exploitation techniques. Attackers could leverage this double free condition to corrupt kernel memory structures, potentially leading to privilege escalation or denial of service attacks. The vulnerability is particularly concerning in environments where s390x systems are deployed, as it affects the fundamental process management capabilities of the kernel. The flaw demonstrates a classic memory safety issue that aligns with CWE-415, which describes improper handling of memory allocation and deallocation sequences. The condition occurs specifically during the fork() system call failure path, making it relevant to the ATT&CK technique T1059.003 which covers command and scripting interpreter execution, as such memory corruption could enable further attack vectors through compromised system processes.
Mitigation strategies must focus on correcting the timing of pointer clearing operations within the fork() implementation. The recommended fix involves clearing the associated pointer fields in arch_dup_task_struct() immediately after the new task is successfully copied, rather than relying on copy_thread() to handle this cleanup. This approach prevents the scenario where freed memory regions could be accessed again through stale pointers. The RI flag remains cleared in copy_thread() as it resides in thread stack memory that is copied during the process, maintaining the proper separation of concerns. System administrators should ensure that affected systems are patched promptly, as the vulnerability can be triggered through normal system operation during fork() calls. The fix aligns with kernel security best practices and helps maintain the integrity of memory management operations that are critical to system stability and security. Regular kernel updates and security monitoring are essential to prevent exploitation of such memory corruption vulnerabilities in production environments.