CVE-2026-90307
NoneCVSS
—
EPSS
0.2%
Published
Sep 17, 2026
CISA due date
—
Cloudanix analysis
A bug in the Linux kernel's SRP storage driver can let a malicious storage device read a few bytes of internal memory from the computer that connects to it.
- Exploitation
- Remote Authenticated
- Attacker needs
- Low Privilege
- Complexity
- Moderate
- Impact
- Data Exposure
- Component
- OS kernel
- Class
- Information Disclosure
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
The flaw allows an RDMA/SRP target to cause an initiator to read 8 bytes past the end of a kmalloc-8 receive buffer when processing a truncated SRP_CRED_REQ or SRP_AER_REQ, leaking adjacent heap bytes into the subsequent SRP_CRED_RSP or AER response.
Why it matters to the business
An attacker-controlled storage target can obtain small amounts of kernel memory contents from the initiator, potentially exposing sensitive data such as pointers or slab contents that aid further attacks; the issue affects any Linux system using the SRP initiator over RDMA fabrics.
How an attack unfolds
A malicious SRP target first completes login advertising a small max_ti_iu_len, then sends a deliberately short SRP_CRED_REQ (or SRP_AER_REQ) whose byte_len is less than the structure size; the initiator reads beyond the allocated buffer, copies the out-of-bounds bytes into the response, and returns them to the target.
How to fix it
Apply the upstream kernel patch that adds length checks before reading fixed-size fields in srp_process_cred_req(), srp_process_aer_req(), and rsp->data; upgrade to a kernel containing the fix for CVE-2026-90307.
How to confirm the fix worked
Confirm the patch is present by inspecting srp_recv_done() and the process_cred_req / process_aer_req functions for the new minimum-length checks; recompile with KASAN and verify the slab-out-of-bounds report no longer occurs on short responses.
Typical attack path
- Establish an SRP login with the target advertising a small max_ti_iu_len value
- Send a truncated SRP_CRED_REQ (or SRP_AER_REQ) whose length is smaller than the expected fixed-size structure
- Trigger srp_recv_done() to process the response without length validation
- Receive the leaked 8 bytes inside the corresponding SRP_CRED_RSP or AER response
How to detect it
Search kernel logs for KASAN slab-out-of-bounds reports mentioning srp_recv_done and kmalloc-8; inspect RDMA/SRP login responses for unusually small max_ti_iu_len values advertised by remote targets.
What your security team should do
- Prioritize kernel updates on all systems using the SRP initiator module
- Restrict RDMA fabric access to trusted targets only
- Monitor for unusual SRP login parameters advertising very small max_ti_iu_len values
The record
In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: fix heap information leak on a truncated SRP_CRED_REQ srp_recv_done() passes wc->byte_len to srp_process_rsp(). It passes nothing to srp_process_cred_req() and srp_process_aer_req(), which read fixed-size fields from the receive buffer without checking that those fields were received. The buffer size is max_ti_iu_len, which comes from the login response and is not validated. A target that advertises 8 and then sends an 8-byte SRP_CRED_REQ makes the initiator read req->tag from beyond the end of the buffer. req->tag is copied into the SRP_CRED_RSP and sent back, so those bytes reach the target. SRP_AER_REQ behaves the same way and also reads req->lun. The leak is 8 bytes per response. max_ti_iu_len 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 srp_recv_done+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 srp_process_rsp() has the same problem: only resp_data_len is checked before it is read. Drop a request that is shorter than the structure being parsed, and check byte_len before the tsk_mgmt read.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|