CVE-2026-90307RDMA/srp: fix heap information leak on a truncated SRP_CRED_REQ
Updated under an hour ago ()
Does this affect you?
It affects Linux. Add what you run to find out whether that includes you.
No exploitation reported and no EPSS estimate yet.
Do this next
Free account, 1 product
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.
- CVSS
- Not yet scored
- Weakness (CWE)
- Not given
- Known exploited
- Not in CISA's KEV catalog
- EPSS (exploitation in the next 30 days)
- Not loaded for this CVE
- Assigned by
- Linux
- NVD analysis
- Received
- Record last updated
- Oct 19, 2026
- First seen by InfoSec Signals
- Oct 9, 2026
Affected products
Linux Linux linux:linux (from the name) | from bb12588a38e6db85e01dceadff7bc161fc92e7d2 before 3f7fdf561f1ec3b523c39708df00bd808671668d; from bb12588a38e6db85e01dceadff7bc161fc92e7d2 before 138eb2f0ef02adfe6ad126afad5b54c56b5046ee; from bb12588a38e6db85e01dceadff7bc161fc92e7d2 before 3787f4c3e0d813d6c56be9f6dfaf66f8551fb0a7; from bb12588a38e6db85e01dceadff7bc161fc92e7d2 before 0e7ba617514902501514d577647d866e670dad90; from bb12588a38e6db85e01dceadff7bc161fc92e7d2 before 001adf2fe87d1ab677c014a97467bbea5153ae5f; from bb12588a38e6db85e01dceadff7bc161fc92e7d2 before dc2272c00d7c00ee2a69b57f7ca9caaefcbdb8cd; from bb12588a38e6db85e01dceadff7bc161fc92e7d2 before fa1b33fdab3e79dce83721ead3220200a2dbec22; from bb12588a38e6db85e01dceadff7bc161fc92e7d2 before 961ac0f0c5e414abdd6b33fae84b311d9fde0bd0 | CNA record |
References
- https://git.kernel.org/stable/c/3f7fdf561f1ec3b523c39708df00bd808671668d
- https://git.kernel.org/stable/c/138eb2f0ef02adfe6ad126afad5b54c56b5046ee
- https://git.kernel.org/stable/c/3787f4c3e0d813d6c56be9f6dfaf66f8551fb0a7
- https://git.kernel.org/stable/c/0e7ba617514902501514d577647d866e670dad90
- https://git.kernel.org/stable/c/001adf2fe87d1ab677c014a97467bbea5153ae5f
- https://git.kernel.org/stable/c/dc2272c00d7c00ee2a69b57f7ca9caaefcbdb8cd
- https://git.kernel.org/stable/c/fa1b33fdab3e79dce83721ead3220200a2dbec22
- https://git.kernel.org/stable/c/961ac0f0c5e414abdd6b33fae84b311d9fde0bd0
The CVE record on cve.org NVD's entry
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.