CVE-2022-49450 is a vulnerability in the Linux kernel's rxrpc protocol implementation, specifically in the handling of the listen() system call for AF_RXRPC sockets. The issue arises because the listen() handler allows setting the backlog queue size up to 32 (if the sysctl parameter is increased), but the underlying preallocation circular buffers used to manage calls have only 32 slots, with one slot always reserved as a dead slot due to the use of CIRC_CNT(). This discrepancy means that setting the backlog to 32 causes an off-by-one error where one too many calls are preallocated. When the socket is closed, the function rxrpc_service_prealloc_one() allocates an excess call, and rxrpc_discard_prealloc() fails to remove it because it incorrectly believes the ring buffer is empty. Subsequently, rxrpc_release_calls_on_socket() attempts to abort these calls but triggers a kernel NULL pointer dereference because the call's peer pointer is not set. This results in a kernel oops (crash) with a NULL pointer dereference at rxrpc_send_abort_packet(). The vulnerability can be triggered by closing a socket after setting the backlog to 32, causing a denial of service via kernel crash. The root cause is a mismatch between the maximum backlog allowed and the actual ring buffer capacity, which was fixed by limiting the backlog to RXRPC_BACKLOG_MAX - 1 to align with the buffer size. No known exploits are reported in the wild, and no CVSS score has been assigned yet. The vulnerability affects Linux kernel versions identified by the given commit hashes, indicating a code-level fix rather than a version number range. This bug can be triggered locally or remotely if an attacker can create and close AF_RXRPC sockets with a high backlog, leading to kernel instability or denial of service.

For European organizations, the impact of CVE-2022-49450 primarily involves potential denial of service conditions on Linux systems utilizing the rxrpc protocol, which is commonly used in distributed computing environments and certain enterprise applications. A successful exploitation could cause kernel crashes, leading to system downtime, loss of availability, and potential disruption of critical services. This is particularly concerning for organizations running Linux-based servers in telecommunications, cloud infrastructure, or enterprise environments where AF_RXRPC sockets are in use. While this vulnerability does not appear to allow privilege escalation or remote code execution, the resulting kernel oops could be leveraged as part of a larger attack chain to disrupt operations or cause instability. Given the widespread use of Linux in European data centers and critical infrastructure, unpatched systems could experience service interruptions. However, the requirement to manipulate the backlog parameter and close sockets suggests that exploitation may require local access or specific network conditions, somewhat limiting the attack surface. Nonetheless, organizations with exposed Linux servers or multi-tenant environments should consider this vulnerability a risk to system stability and availability.

To mitigate CVE-2022-49450, European organizations should: 1) Apply the official Linux kernel patches that fix the backlog handling in the rxrpc listen() implementation as soon as they become available from their Linux distribution vendors. 2) Monitor and restrict the use of AF_RXRPC sockets where possible, especially in environments where untrusted users or processes may have the ability to create or manipulate such sockets. 3) Implement kernel crash monitoring and alerting to detect any suspicious kernel oops events related to rxrpc. 4) Limit the sysctl parameters that control the backlog size for rxrpc sockets to prevent setting values that exceed the safe threshold (RXRPC_BACKLOG_MAX - 1). 5) Employ strict access controls and containerization to reduce the risk of local exploitation by unprivileged users. 6) Regularly update Linux kernels to incorporate security fixes and maintain system stability. 7) For critical systems, consider disabling rxrpc support if it is not required, reducing the attack surface. These steps go beyond generic advice by focusing on controlling the specific backlog parameter, monitoring kernel stability, and restricting AF_RXRPC socket usage.