Nixpkgs security tracker

Login with GitHub
⚠️ You are using a production deployment that is still only suitable for demo purposes. Any work done in this might be wiped later without notice.

Suggestion detail

Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
xprtrdma: Check frwr_wp_create() during connect

In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Check frwr_wp_create() during connect frwr_wp_create() creates the singleton Memory Region used to encode padding for Write chunks whose payload length is not XDR-aligned. Its failure paths return a negative errno and leave ep->re_write_pad_mr set to NULL. rpcrdma_xprt_connect() currently ignores that return value. If frwr_wp_create() fails after the rest of the connection setup succeeds, xprt_rdma_connect_worker() treats the connection attempt as successful and sets XPRT_CONNECTED. A later NFS/RDMA read with a non-4-byte-aligned receive page length reaches rpcrdma_encode_write_list(), passes the NULL write-pad MR to encode_rdma_segment(), and dereferences it. This is locally triggerable on an NFS/RDMA client after a connect or reconnect hits a local MR allocation, DMA-map, MR-map, or post-send failure; a remote peer alone cannot force the local MR setup failure. Check the return value and fail the connect as -ENOTCONN, matching the adjacent setup failures. This keeps XPRT_CONNECTED clear and lets the normal reconnect path retry.

Affected products

Linux
  • <0f13fc7c7d2e0427517e63c739277a4cd338b0c5
  • <6b7be4f3feae322f1c2c40a3bdc99db93574a49e
  • <ef3b79edf14b6bfb0d21a26ccb0463f9cf82c6a9
  • <3b252fe1778b2cdd68283146455929801bc2abd7
  • =<6.6.*
  • =<*
  • ==5.16
  • <dd798b76a3481e392820c3ae86ed4592858c6b0f
  • <7471e66373a4444a57ef2192f8c4081202c54f45
  • =<6.18.*
  • =<6.12.*
  • =<7.1.*
  • <5.16
  • =<6.1.*