CVE-2026-90307: RDMA/srp: fix heap information leak on a truncated SRP_CRED_REQ
In the Linux kernel, the following vulnerability has been resolved:
RDMA/srp: fix heap information leak on a truncated SRPCREDREQ
srprecvdone() passes wc->bytelen to srpprocessrsp(). It passes nothing to srpprocesscredreq() and srpprocessaerreq(), which read fixed-size fields from the receive buffer without checking that those fields were received.
The buffer size is maxtiiulen, which comes from the login response and is not validated. A target that advertises 8 and then sends an 8-byte SRPCREDREQ makes the initiator read req->tag from beyond the end of the buffer. req->tag is copied into the SRPCREDRSP and sent back, so those bytes reach the target. SRPAERREQ behaves the same way and also reads req->lun.
The leak is 8 bytes per response. maxtiiulen also decides which slab cache the buffer comes from. With 8 the buffer is a kmalloc-8 object and the read is entirely outside it:
BUG: KASAN: slab-out-of-bounds in srprecvdone+0x172b/0x1aa0 Read of size 8 at addr ffff888104714da8 by task kworker/u8:3/50 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 8-byte region [ffff888104714da0, ffff888104714da8)
Without KASAN the returned bytes are whatever is next in the slab. One run returned ".strtab".
rsp->data[3] in srpprocessrsp() has the same problem: only respdatalen is checked before it is read.
Drop a request that is shorter than the structure being parsed, and check bytelen before the tskmgmt read.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In srp_recv_done()/SRP request handling, drop any SRP_CRED_REQ (and SRP_AER_REQ) that is shorter than the structure being parsed, and validate req->byte_len (or equivalent wc->byte_len/len value) before reading fixed-size fields such as req->tag and req->lun.
Linux kernel SRP (RDMA) Validate req length/byte_len before parsing SRP_CRED_REQ (including req->tag and req->lun) = check byte_len/req size before tsk_mgmt read; drop requests shorter than the structure being parsed - Configuration
In srp_process_rsp(), validate resp_data_len before accessing fixed-size fields in resp->data (e.g., rsp->data[3]) and ensure srp_recv_done() passes the correct wc->byte_len so reads cannot occur outside the received buffer.
Linux kernel SRP (RDMA) Validate response length before accessing srp_process_rsp() data (resp->data[3]) = validate resp_data_len before reading; ensure read stays within buffer length passed to srp_process_rsp()
Event History
Frequently Asked Questions
Who can trigger the information leak?
An SRP target can trigger it against an SRP initiator by advertising a small max_ti_iu_len value during login and then sending a truncated SRP_CRED_REQ or SRP_AER_REQ. This makes the initiator read beyond its receive buffer and return leaked heap data to the target.
What information is exposed and how much can be leaked?
The out-of-bounds data includes the credential-request tag copied into an SRP_CRED_RSP; SRP_AER_REQ can also read the LUN. The described leak is 8 bytes per response.
How can I determine whether a system has encountered this condition?
A vulnerable system may report a KASAN slab-out-of-bounds read in srp_recv_done, with a read of size 8 immediately beyond an allocated kmalloc-8 receive buffer. The condition is associated with a target advertising max_ti_iu_len of 8 and sending an 8-byte request.