CVE-2026-90307
RDMA/srp: fix heap information leak on a truncated SRP_CRED_REQ
Published Sep 17, 2026
CVSS n/a
EPSS < 1%
KEV · Not listed
Description
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.
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 Products
-
CVE record
-
NVD configurations
No data
-
Red Hat packages
No data
-
OpenCVE enrichment
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | |||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Linux | Linux | unaffected |
|
|||||||||||||||||||||||||||||||||
| Linux | Linux | affected |
|
No data.
No data.
| Vendor | Product | Versions | ||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Linux | Linux Kernel |
|
||||||||||||||||||||||||||||||||||||||||||||
| Linux | Linux Kernel |
|
Remediation
Tracking
Advisories
| Source | ID | Title |
|---|---|---|
 Debian DLA |
DLA-4817-1 | linux-6.12 security update |
| Debian DLA |
DLA-4841-1 | linux security update |
 Debian DSA |
DSA-6528-1 | linux security update |
 Ubuntu USN |
USN-8961-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-9019-1 | Linux kernel (Azure) vulnerabilities |
| Ubuntu USN |
USN-9020-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-9022-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-9023-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-9024-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-9025-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-9026-1 | Linux kernel (Azure) vulnerabilities |
| Ubuntu USN |
USN-9029-1 | Linux kernel (Raspberry Pi) vulnerabilities |
| Ubuntu USN |
USN-9039-1 | Linux kernel (Azure CVM) vulnerabilities |
| Ubuntu USN |
USN-9040-1 | Linux kernel (Low Latency NVIDIA) vulnerabilities |
| Ubuntu USN |
USN-9066-1 | Linux kernel (HWE) vulnerabilities |
| Ubuntu USN |
USN-9091-1 | Linux kernel (NVIDIA Tegra) vulnerabilities |
Metrics
No CVSS v4.0
No CVSS v3.1
No CVSS v3.0
No CVSS v2
This CVE is not in the KEV list.
Exploit prediction score: < 1% (0.216% probability within 30 days)
Key SSVC decision points have not yet been added.
References
History
Sep 19, 2026 3:30 PM
Weaknesses updated
View changes
| Type | Values Removed | Values Added |
|---|---|---|
| Weaknesses | CWE-119 CWE-200 |
Sep 17, 2026 4:30 PM
Description updated. Title updated. First appearance in the feed. Affected versions updated. Affected vendors updated. Added references
View changes
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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. | |
| Title | RDMA/srp: fix heap information leak on a truncated SRP_CRED_REQ | |
| First Time appeared |
Linux
Linux linux Kernel |
|
| CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Linux
Linux linux Kernel |
|
| References |
|
|
