CVE-2022-50091 in Linux
Summary
by MITRE • 06/18/2025
In the Linux kernel, the following vulnerability has been resolved:
locking/csd_lock: Change csdlock_debug from early_param to __setup
The csdlock_debug kernel-boot parameter is parsed by the early_param() function csdlock_debug(). If set, csdlock_debug() invokes static_branch_enable() to enable csd_lock_wait feature, which triggers a panic on arm64 for kernels built with CONFIG_SPARSEMEM=y and CONFIG_SPARSEMEM_VMEMMAP=n.
With CONFIG_SPARSEMEM_VMEMMAP=n, __nr_to_section is called in static_key_enable() and returns NULL, resulting in a NULL dereference because mem_section is initialized only later in sparse_init().
This is also a problem for powerpc because early_param() functions are invoked earlier than jump_label_init(), also resulting in static_key_enable() failures. These failures cause the warning "static key 'xxx' used before call to jump_label_init()".
Thus, early_param is too early for csd_lock_wait to run static_branch_enable(), so changes it to __setup to fix these.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/30/2025
The vulnerability CVE-2022-50091 represents a critical timing issue within the Linux kernel's locking subsystem that affects the csd_lock_wait feature implementation. This flaw manifests when the kernel processes the csdlock_debug boot parameter through the early_param() function during the kernel initialization phase. The csdlock_debug parameter is designed to enable debugging features for the csd_lock mechanism, which is part of the kernel's locking infrastructure. When this parameter is set, the system attempts to invoke static_branch_enable() to activate the csd_lock_wait functionality, but this occurs at an inappropriate stage in the kernel boot process. The vulnerability stems from the fact that early_param() functions execute before certain subsystems are fully initialized, creating a race condition that can lead to system instability.
The technical root cause of this vulnerability lies in the improper timing of kernel initialization sequences and the interaction between different subsystems. When kernels are built with CONFIG_SPARSEMEM=y and CONFIG_SPARSEMEM_VMEMMAP=n, the system attempts to call __nr_to_section() within static_key_enable() during the early boot phase. This function returns NULL because mem_section data structures are not yet initialized, leading to a NULL pointer dereference that triggers a kernel panic. The issue affects both arm64 and powerpc architectures due to their different initialization timelines, where early_param() functions are invoked before jump_label_init() has completed. This creates a scenario where static_key_enable() fails with the warning "static key 'xxx' used before call to jump_label_init()", indicating that the static key infrastructure is being accessed before it's properly initialized. The vulnerability is classified under CWE-665 Improper Initialization and represents a classic case of improper ordering of initialization steps in kernel code.
The operational impact of this vulnerability is severe as it can cause complete system crashes during kernel boot, making affected systems unreliable and potentially unusable. The panic occurs specifically when the kernel attempts to enable the csd_lock_wait feature through the csdlock_debug parameter, which is typically used for debugging purposes but can be inadvertently enabled in production environments. This vulnerability affects systems running Linux kernels where the specific memory management configuration options are enabled, particularly those using sparse memory management without virtual memory mapping. The issue is particularly concerning because it can be triggered through normal kernel boot parameters without requiring special privileges or malicious input, making it an attractive target for exploitation that could lead to denial-of-service attacks or system compromise. The vulnerability affects the fundamental locking mechanisms of the kernel, potentially impacting system stability across all architectures that use the affected memory management configurations.
The mitigation strategy for CVE-2022-50091 involves changing the implementation from early_param() to __setup() for handling the csdlock_debug parameter. This modification ensures that the csd_lock_wait feature initialization occurs at the appropriate time in the kernel boot process, after all necessary subsystems including jump_label_init() have completed their initialization. The fix addresses the timing issue by delaying the execution of static_branch_enable() until after the static key infrastructure is properly initialized, thereby preventing NULL pointer dereferences and kernel panics. System administrators should ensure that kernel updates containing this fix are applied to all affected systems, particularly those using the specific memory management configurations mentioned in the vulnerability description. The fix aligns with ATT&CK technique T1499.004 for Denial of Service via Resource Exhaustion and represents a proper initialization sequence management approach. Additionally, organizations should review their kernel boot parameter configurations to ensure that the csdlock_debug parameter is not inadvertently enabled in production environments, as this would expose systems to the vulnerability. The change from early_param() to __setup() represents a fundamental correction in kernel initialization timing that prevents the race condition between subsystem initialization and feature activation, thereby maintaining system stability and preventing unauthorized privilege escalation through kernel memory management vulnerabilities.