CVE-2026-82942 in bRPC
Summary
by MITRE • 10/22/2026
A data race in the RDMA transport of Apache bRPC (versions < 1.18.0) allows a remote client to crash the server process (denial of service) when RDMA is enabled at build time and runtime.
Root Cause: When a bRPC server negotiates RDMA with a client, the handshake completes on the TCP fd, but the server kept parsing that fd afterwards as if it were still an RPC channel. The TCP-fd input stream and the RDMA QP input stream (driven by CQ events) shared the same Socket::_read_buf, preferred_index and parsing_context without synchronization. In addition, CQ event processing could start while the handshake parsing was still in progress, and the handshake ACK phase could consume bytes belonging to the next protocol. A remote, unauthenticated client that has completed the RDMA handshake can send data on the TCP fd at the same time RDMA messages are being processed, corrupting the shared input buffer and parser state and crashing the server process (CWE-362, availability impact).
Affected Scenarios: Use a bRPC server with RDMA support enabled (built with BRPC_WITH_RDMA and serving rdma:// / SOCKET_MODE_RDMA sockets) and accept connections from untrusted clients. Deployments without RDMA are not affected.
How to Fix: (Choose one of the following options) 1. Upgrade bRPC to version 1.18.0, which fixes this issue. 2. Apply this patch: https://github.com/apache/brpc/pull/3505
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in Apache bRPC versions prior to 1.18.0 represents a critical concurrency flaw within the Remote Direct Memory Access transport layer, specifically manifesting as a data race condition that leads to server process termination and denial of service. This issue arises from improper synchronization mechanisms when handling concurrent input streams during the RDMA handshake and subsequent message processing phases. The root cause lies in the shared state management between two distinct communication channels: the Transmission Control Protocol file descriptor used for initial negotiation and the Queue Pair associated with RDMA operations driven by Completion Queue events. Both of these disparate I/O sources incorrectly reference a common Socket::_read_buf, preferred_index, and parsing_context without adequate mutual exclusion or atomicity guarantees. This architectural oversight allows race conditions to occur where data integrity is compromised because multiple threads attempt to read from and modify the same buffer simultaneously.
During the operational lifecycle of an RDMA-enabled bRPC server, the handshake process initially utilizes a TCP file descriptor to establish connectivity with a remote client. However, upon completion of this negotiation phase, the system fails to properly isolate the subsequent RDMA message processing logic from the residual state associated with the TCP connection. Consequently, while the server continues to parse input on what it believes is still an RPC channel via the TCP fd, it simultaneously processes incoming data through the RDMA Queue Pair triggered by Completion Queue events. These two streams share critical internal structures including the read buffer and parsing context without any synchronization primitives such as mutexes or locks. This lack of isolation means that operations performed by one stream can inadvertently overwrite or corrupt the state expected by the other, leading to undefined behavior within the parser logic.
The practical impact of this vulnerability is severe for deployments where RDMA support is enabled both at build time and runtime. An unauthenticated remote client capable of completing the initial RDMA handshake can exploit this race condition by sending data over the TCP file descriptor while the server is actively processing RDMA messages via Completion Queue events. The concurrent access corrupts the shared input buffer and parser state, causing the bRPC server process to crash due to invalid memory accesses or logic errors within the parsing routine. This results in a complete denial of service for all clients connected to that specific server instance. According to standard vulnerability classifications, this aligns with CWE-362, which denotes concurrent execution using shared resources with improper synchronization. From an offensive security perspective, such as the MITRE ATT&CK framework, this behavior facilitates availability impacts by allowing attackers to disrupt critical infrastructure services through resource exhaustion or process termination techniques.
Mitigation strategies for this vulnerability are straightforward and primarily involve software updates or configuration changes depending on organizational constraints. The recommended primary action is to upgrade Apache bRPC to version 1.18.0 or later, where the developers have implemented proper synchronization mechanisms to isolate the TCP handshake parsing from RDMA message processing. This ensures that shared resources like read buffers are protected by appropriate locking strategies during concurrent access periods. For organizations unable to immediately update their software stack due to compatibility requirements or deployment cycles, applying the specific patch available via pull request 3505 on the Apache bRPC GitHub repository provides a targeted fix for this concurrency issue. Additionally, administrators should assess whether RDMA is strictly necessary for their use case; disabling RDMA support at either build time by omitting the BRPC_WITH_RDMA flag or at runtime by not serving rdma:// sockets effectively eliminates exposure to this specific vulnerability vector since the affected code paths will not be executed.