CVE-2026-90307
CVE CVE-2026-90307EUVD EUVD-2026-81968Published 2026-09-17T16:08:29.000Z
What the advisory describes
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.
Source: EUVD (ENISA), in the words of the advisory.
Products the advisory names
These come from the advisory itself, not from any check we performed.
- Linux — Linux bb12588a38e6db85e01dceadff7bc161fc92e7d2 <001adf2fe87d1ab677c014a97467bbea5153ae5f; bb12588a38e6db85e01dceadff7bc161fc92e7d2 <138eb2f0ef02adfe6ad126afad5b54c56b5046ee; patch: 6.1.188; patch: 7.2.6; patch: 0; bb12588a38e6db85e01dceadff7bc161fc92e7d2 <3f7fdf561f1ec3b523c39708df00bd808671668d; patch: 6.6.157; bb12588a38e6db85e01dceadff7bc161fc92e7d2 <dc2272c00d7c00ee2a69b57f7ca9caaefcbdb8cd; patch: 7.3-rc1; patch: 6.18.52; patch: 6.12.110; 2.6.37; patch: 5.10.270; bb12588a38e6db85e01dceadff7bc161fc92e7d2 <3787f4c3e0d813d6c56be9f6dfaf66f8551fb0a7; bb12588a38e6db85e01dceadff7bc161fc92e7d2 <fa1b33fdab3e79dce83721ead3220200a2dbec22; bb12588a38e6db85e01dceadff7bc161fc92e7d2 <961ac0f0c5e414abdd6b33fae84b311d9fde0bd0; patch: 5.15.221; bb12588a38e6db85e01dceadff7bc161fc92e7d2 <0e7ba617514902501514d577647d866e670dad90
The versions shown are the advisory's own. Patchlage compares no version numbers and derives no judgement from them — which version is installed is something a person has to look up.
Carried in the product catalogue
An estate covering these products can be recorded in Patchlage. An advisory about them appears in the next morning's situation report.
- Linux — Linux
Does this concern one of your customers?
This page cannot answer that — it does not know your estate. Whoever has recorded their environments gets the answer the morning after publication, together with a paragraph they can forward to the customer unedited.
Try it for 28 daysPatchlage reports hits and suspected hits. About everything else this system says nothing — neither this page nor the situation report ever claims that an estate is safe.