CVE-2026-90307 in Linux
Summary
by MITRE • 09/17/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The Linux kernel contains a critical heap information leak vulnerability within the RDMA/srp subsystem, specifically affecting the handling of SRP_CRED_REQ and SRP_AER_REQ messages during remote direct memory access operations. This flaw arises from an improper validation of buffer lengths before accessing fixed-size fields in received data structures. The function srp_recv_done is responsible for processing incoming work completions and passes the byte length to srp_process_rsp, yet it fails to pass this critical size information to srp_process_cred_req and srp_process_aer_req. Consequently, these functions proceed to read specific fields such as req->tag from SRP_CRED_REQ and req->lun from SRP_AER_REQ without verifying that the received buffer contains sufficient data to support those reads. This oversight creates a scenario where an attacker can exploit the lack of bounds checking to extract sensitive kernel memory contents.
The root cause lies in the reliance on max_ti_iu_len, which is derived from the login response and not adequately validated by the initiator before processing subsequent messages. A malicious target can advertise a small maximum transfer unit length, such as eight bytes, and then send an SRP_CRED_REQ message that is exactly eight bytes long. When srp_process_cred_req attempts to read req->tag, which requires more than eight bytes or accesses memory beyond the allocated buffer boundary depending on alignment and structure layout, it reads data from outside the intended allocation region. The kernel allocates buffers using slab caches like kmalloc-8 for small sizes, meaning a request claiming only eight bytes results in an eight-byte allocation. Reading req->tag exceeds this limit, causing a heap out-of-bounds read that accesses memory immediately following the allocated block. This behavior is mirrored by SRP_AER_REQ when reading req->lun, creating multiple vectors for information disclosure within the same subsystem.
The operational impact of this vulnerability allows an authenticated remote attacker to leak up to eight bytes of kernel heap data per response packet back to the target system. Under normal conditions without debugging tools like Kernel Address Sanitizer enabled, these leaked bytes contain whatever memory content happens to reside in the slab allocator adjacent to the freed or active allocation. In observed instances, this has resulted in the leakage of internal kernel strings such as .strtab sections from object files. While eight bytes may seem limited, they can reveal pointers, structure offsets, or other metadata that aids further exploitation attempts against the host system. The vulnerability effectively bypasses standard memory safety protections because it relies on predictable slab layout behavior rather than a traditional buffer overflow that crashes the kernel immediately, making detection difficult without specialized monitoring tools.
To mitigate this risk, developers must enforce strict length validation before parsing any fixed-size fields from network-received buffers in the SRP subsystem. The fix involves modifying srp_recv_done to pass the byte_len parameter to both srp_process_cred_req and srp_process_aer_req functions so they can verify that the incoming message meets minimum size requirements for their respective structures. Additionally, checks must be implemented to ensure that requests shorter than the expected structure are dropped immediately rather than processed partially. This includes validating resp_data_len before accessing rsp->data[3] in srp_process_rsp and ensuring tsk_mgmt operations respect buffer boundaries. These changes align with CWE-125 Out-of-bounds Read standards, which classify this type of flaw as a failure to validate input length prior to memory access. From an ATT&CK perspective, this vulnerability facilitates Tactic TA0042 Command and Control through potential data exfiltration channels or reconnaissance via information leakage that aids in bypassing security controls on the target host.