CVE-2022-49450 in Linux
Summary
by MITRE • 02/26/2025
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix listen() setting the bar too high for the prealloc rings
AF_RXRPC's listen() handler lets you set the backlog up to 32 (if you bump up the sysctl), but whilst the preallocation circular buffers have 32 slots in them, one of them has to be a dead slot because we're using CIRC_CNT().
This means that listen(rxrpc_sock, 32) will cause an oops when the socket is closed because rxrpc_service_prealloc_one() allocated one too many calls and rxrpc_discard_prealloc() won't then be able to get rid of them because it'll think the ring is empty. rxrpc_release_calls_on_socket() then tries to abort them, but oopses because call->peer isn't yet set.
Fix this by setting the maximum backlog to RXRPC_BACKLOG_MAX - 1 to match the ring capacity.
BUG: kernel NULL pointer dereference, address: 0000000000000086 ... RIP: 0010:rxrpc_send_abort_packet+0x73/0x240 [rxrpc]
Call Trace: ? __wake_up_common_lock+0x7a/0x90 ? rxrpc_notify_socket+0x8e/0x140 [rxrpc]
? rxrpc_abort_call+0x4c/0x60 [rxrpc]
rxrpc_release_calls_on_socket+0x107/0x1a0 [rxrpc]
rxrpc_release+0xc9/0x1c0 [rxrpc]
__sock_release+0x37/0xa0 sock_close+0x11/0x20 __fput+0x89/0x240 task_work_run+0x59/0x90 do_exit+0x319/0xaa0
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 05/13/2025
The vulnerability described in CVE-2022-49450 resides within the Linux kernel's rxrpc subsystem, specifically affecting the AF_RXRPC protocol implementation. This protocol is designed to support remote execution of RPC calls over the network and operates through a specialized socket interface. The issue manifests when a socket is configured with a backlog parameter set to its maximum allowable value, creating a fundamental mismatch between the configured backlog capacity and the actual preallocation ring buffer size. The rxrpc subsystem employs circular buffer structures for managing call preallocation, where CIRC_CNT() macro is used to determine buffer occupancy, requiring one slot to remain unused as a dead slot to distinguish between empty and full buffer states. When a socket is initialized with listen() using a backlog value of 32, the system allocates one additional call beyond what the underlying ring buffer can accommodate, leading to a critical inconsistency in the buffer management logic.
The technical flaw stems from an arithmetic mismatch in the backlog parameter handling within the rxrpc service preallocation mechanism. The system correctly sets the maximum backlog to RXRPC_BACKLOG_MAX but fails to account for the required dead slot that the circular buffer implementation necessitates. This creates a scenario where rxrpc_service_prealloc_one() allocates one more call than the ring can properly manage, resulting in a state where rxrpc_discard_prealloc() cannot properly clean up the excess allocations because it incorrectly determines the ring to be empty. The subsequent call to rxrpc_release_calls_on_socket() attempts to abort the improperly allocated calls, but encounters a NULL pointer dereference when trying to access call->peer field, which has not yet been initialized during the premature allocation process. This NULL pointer dereference ultimately triggers a kernel oops condition that can lead to system instability and potential denial of service.
The operational impact of this vulnerability extends beyond simple system crashes, as it represents a critical kernel memory management flaw that can be exploited to cause system instability. The vulnerability specifically affects systems running Linux kernels with AF_RXRPC support where applications configure socket backlog parameters to their maximum values, creating a scenario where closing such sockets results in kernel panics. The flaw is particularly concerning because it operates at the kernel level, meaning that any application or service utilizing rxrpc sockets with maximum backlog values could trigger the condition. From a security perspective, this vulnerability could potentially be leveraged to cause denial of service attacks against systems running affected kernels, as adversaries could repeatedly trigger socket closure sequences to induce kernel oops conditions. The vulnerability also demonstrates poor adherence to buffer management principles and highlights the importance of considering circular buffer implementations' inherent constraints when designing system interfaces. The attack surface is limited to systems utilizing the rxrpc protocol specifically, but the impact is severe as it affects core kernel functionality.
The mitigation strategy for CVE-2022-49450 involves implementing a simple but critical fix within the rxrpc subsystem's backlog parameter handling. The solution requires adjusting the maximum allowable backlog value to RXRPC_BACKLOG_MAX - 1, which aligns the configured backlog with the actual available ring capacity while accounting for the required dead slot. This modification ensures that the preallocation logic does not attempt to allocate more calls than the underlying circular buffer can properly manage, preventing the inconsistent state that leads to the NULL pointer dereference. The fix directly addresses the root cause by ensuring that rxrpc_service_prealloc_one() never allocates beyond the ring capacity, thereby preventing rxrpc_discard_prealloc() from encountering the empty ring condition and avoiding the subsequent call to rxrpc_release_calls_on_socket() that triggers the kernel oops. System administrators should ensure that affected kernels are updated to versions containing this fix, and applications should avoid setting rxrpc socket backlog values to maximum limits where possible. From a compliance perspective, this vulnerability aligns with CWE-129, which addresses improper validation of array indices, and represents a failure to properly validate input parameters against system constraints. The fix also demonstrates adherence to proper kernel memory management practices as outlined in various security frameworks, ensuring that resource allocation logic properly accounts for underlying data structure limitations and constraints.