{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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-\u003ebyte_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-\u003etag from beyond the end of the buffer. req-\u003etag 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-\u003elun.  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-\u003edata[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.",
  "id": "DEBIAN-CVE-2026-90307",
  "modified": "2026-09-18T04:47:38.178913323Z",
  "published": "2026-09-17T17:17:28.377Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-90307"
    }
  ],
  "upstream": [
    "CVE-2026-90307"
  ]
}