https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 06:35:15 +0000 https://vulnerability.circl.lu/vuln/cve-2026-72464 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>xprtrdma: Repost Receive buffers for malformed replies</p> <p>rpcrdma_wc_receive() decrements the transport&#39;s Receive count for every completion before it dispatches a successful Receive to rpcrdma_reply_handler(). The handler must post a replacement Receive WR before returning unless ownership of the rep has moved elsewhere, as on the backchannel path.</p> <p>Commit 2ae50ad68cd7 (&#34;xprtrdma: Close window between waking RPC senders and posting Receives&#34;) moved the Receive refill out of rpcrdma_wc_receive(), where it had run ahead of every reply, into rpcrdma_reply_handler() so that the responder&#39;s credit grant could be parsed before reposting. The bad-version and short-reply exits never reach that refill: they recycle the rep and return without calling rpcrdma_post_recvs().</p> <p>A remote peer can therefore drain the client&#39;s posted Receive queue by sending a sustained stream of replies that are shorter than the fixed transport header or that carry an unrecognized RPC/RDMA version. Each such reply consumes one posted Receive without replacing it. Once the queue empties, the peer&#39;s next Send finds no posted Receive and the transport stalls until reconnect.</p> <p>Route both malformed-reply exits through the shared repost tail after recycling the rep, refilling against buf-&gt;rb_credits, the most recent accepted credit grant. Neither exit updates the congestion window, so RPCs admitted under the previous grant remain in flight awaitin…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>xprtrdma: Repost Receive buffers for malformed replies</p> <p>rpcrdma_wc_receive() decrements the transport&#39;s Receive count for every completion before it dispatches a successful Receive to rpcrdma_reply_handler(). The handler must post a replacement Receive WR before returning unless ownership of the rep has moved elsewhere, as on the backchannel path.</p> <p>Commit 2ae50ad68cd7 (&#34;xprtrdma: Close window between waking RPC senders and posting Receives&#34;) moved the Receive refill out of rpcrdma_wc_receive(), where it had run ahead of every reply, into rpcrdma_reply_handler() so that the responder&#39;s credit grant could be parsed before reposting. The bad-version and short-reply exits never reach that refill: they recycle the rep and return without calling rpcrdma_post_recvs().</p> <p>A remote peer can therefore drain the client&#39;s posted Receive queue by sending a sustained stream of replies that are shorter than the fixed transport header or that carry an unrecognized RPC/RDMA version. Each such reply consumes one posted Receive without replacing it. Once the queue empties, the peer&#39;s next Send finds no posted Receive and the transport stalls until reconnect.</p> <p>Route both malformed-reply exits through the shared repost tail after recycling the rep, refilling against buf-&gt;rb_credits, the most recent accepted credit grant. Neither exit updates the congestion window, so RPCs admitted under the previous grant remain in flight awaitin…</p> https://vulnerability.circl.lu/vuln/cve-2026-72464