CVE-2024-50271 in Linux
Summary
by MITRE • 11/19/2024
In the Linux kernel, the following vulnerability has been resolved:
signal: restore the override_rlimit logic
Prior to commit d64696905554 ("Reimplement RLIMIT_SIGPENDING on top of ucounts") UCOUNT_RLIMIT_SIGPENDING rlimit was not enforced for a class of signals. However now it's enforced unconditionally, even if override_rlimit is set. This behavior change caused production issues.
For example, if the limit is reached and a process receives a SIGSEGV signal, sigqueue_alloc fails to allocate the necessary resources for the signal delivery, preventing the signal from being delivered with siginfo. This prevents the process from correctly identifying the fault address and handling the error. From the user-space perspective, applications are unaware that the limit has been reached and that the siginfo is effectively 'corrupted'. This can lead to unpredictable behavior and crashes, as we observed with java applications.
Fix this by passing override_rlimit into inc_rlimit_get_ucounts() and skip the comparison to max there if override_rlimit is set. This effectively restores the old behavior.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/22/2025
This vulnerability affects the Linux kernel's signal handling mechanism and represents a regression in resource limit enforcement that was introduced during a reimplementation of the RLIMIT_SIGPENDING functionality. The issue stems from commit d64696905554 which reworked how the signal pending limit is enforced using ucounts infrastructure. Previously, the UCOUNT_RLIMIT_SIGPENDING rlimit was not consistently enforced for certain signal classes, but the new implementation enforces it unconditionally regardless of whether override_rlimit is set. This change fundamentally altered the signal delivery behavior and created production stability issues.
The technical flaw manifests when a process reaches its signal pending limit and attempts to deliver a signal such as SIGSEGV. The sigqueue_alloc function fails to allocate necessary resources for signal delivery, resulting in the signal not being properly delivered with complete siginfo structure. This prevents applications from correctly identifying fault addresses and handling errors appropriately. The vulnerability specifically impacts applications that rely on detailed signal information for proper error handling and recovery, with reported issues occurring in java applications where the lack of complete signal information leads to unpredictable behavior and system crashes.
From an operational perspective, this vulnerability creates a subtle but critical reliability issue that can be difficult to diagnose from user-space applications. The affected applications remain unaware that the signal limit has been reached, as the system silently fails to deliver complete signal information. This leads to applications behaving unpredictably and potentially crashing when they encounter conditions that would normally trigger proper signal handling. The impact extends beyond simple application failures to potentially compromise system stability in environments where signal-based error recovery is critical.
The fix addresses this by modifying the inc_rlimit_get_ucounts() function to accept an override_rlimit parameter and conditionally skip the comparison against maximum limits when override_rlimit is set. This restoration of the previous behavior ensures that processes can still properly handle signals even when approaching resource limits, maintaining compatibility with existing application expectations and system stability requirements. This approach aligns with the principle of maintaining backward compatibility while addressing the underlying enforcement mechanism that caused the regression. The solution directly addresses the root cause by preserving the override behavior that was previously functional, preventing the silent failure conditions that led to application instability and system crashes in production environments.
This vulnerability maps to CWE-682 Incorrect Calculation and CWE-248 Uncaught Exception, as it involves incorrect resource management calculations and unhandled error conditions that lead to application instability. The operational impact aligns with ATT&CK technique T1489, as it affects system integrity through subtle resource management failures that compromise application behavior and system reliability. The fix maintains the security posture while restoring expected behavior, ensuring that signal-based error handling continues to function properly across all application types including those that depend on detailed signal information for proper operation.