Goal Reached Thanks to every supporter — we hit 100%!

Goal: 1000 CNY · Raised: 1336 CNY

100%

CVE-2026-90307— RDMA/srp: fix heap information leak on a truncated SRP_CRED_REQ

Quick assessment

Affected
Linux Linux
Exploitation
No confirmed in-the-wild exploitation; assess based on exposure
Recommended action
Check the vendor advisory and references for a fixed version. If immediate upgrade is impossible, restrict exposure and increase monitoring.

在 Linux 内核中,以下漏洞已得到修复: RDMA/srp:修复因截断的 SRP_CRED_REQ 导致的堆信息泄露 函数将 传递给 。但该函数未向 和 传递任何参数,而这两个函数在读取接收缓冲区中的固定大小字段时,并未检查这些字段是否已完整接收。 缓冲区的大小为 ,该值来自登录响应,且未经过验证。如果目标端(Target)通告 8 并随后发送一个 8 字节的 ,发起端(Initiator)就会从缓冲区末尾之外读取 。由于 会被复制到 并回发给目标端,因此这些字节最终会到达目标端。 的行为相同,并且还会读取 。

AI Predicted 5.5 Difficulty: Moderate

Possible ATT&CK Techniques 1 AI

T1203 · Exploitation for Client Execution

Affected Version Matrix 18

VendorProduct Version RangeStatus
Linux Linux bb12588a38e6db85e01dceadff7bc161fc92e7d2< 3f7fdf561f1ec3b523c39708df00bd808671668d affected
bb12588a38e6db85e01dceadff7bc161fc92e7d2< 138eb2f0ef02adfe6ad126afad5b54c56b5046ee affected
bb12588a38e6db85e01dceadff7bc161fc92e7d2< 3787f4c3e0d813d6c56be9f6dfaf66f8551fb0a7 affected
bb12588a38e6db85e01dceadff7bc161fc92e7d2< 0e7ba617514902501514d577647d866e670dad90 affected
bb12588a38e6db85e01dceadff7bc161fc92e7d2< 001adf2fe87d1ab677c014a97467bbea5153ae5f affected
bb12588a38e6db85e01dceadff7bc161fc92e7d2< dc2272c00d7c00ee2a69b57f7ca9caaefcbdb8cd affected
bb12588a38e6db85e01dceadff7bc161fc92e7d2< fa1b33fdab3e79dce83721ead3220200a2dbec22 affected
bb12588a38e6db85e01dceadff7bc161fc92e7d2< 961ac0f0c5e414abdd6b33fae84b311d9fde0bd0 affected
… +10 more rows
Get alerts for future matching vulnerabilities Log in to subscribe

I. Basic Information for CVE-2026-90307

Vulnerability Information

Have questions about the vulnerability? See if Shenlong's analysis helps!
View Shenlong Deep Dive ↗

Although we use advanced large model technology, its output may still contain inaccurate or outdated information.Shenlong tries to ensure data accuracy, but please verify and judge based on the actual situation.

Vulnerability Title
RDMA/srp: fix heap information leak on a truncated SRP_CRED_REQ
Source: CVE Program / CVE List V5
Vulnerability 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.
Source: CVE Program / CVE List V5
CVSS Information
N/A
Source: CVE Program / CVE List V5
Vulnerability Type
N/A
Source: CVE Program / CVE List V5

Affected Products

Vendor Product Affected Versions CPE Subscribe
Linux Linux bb12588a38e6db85e01dceadff7bc161fc92e7d2 ~ 3f7fdf561f1ec3b523c39708df00bd808671668d -
Linux Linux 2.6.37 -

II. Public POCs for CVE-2026-90307

# POC Description Source Link Shenlong Link
AI-Generated POC Premium

No public POC found.

Login to generate AI POC

III. Intelligence Information for CVE-2026-90307

登录查看更多情报信息。

Patches & Fixes for CVE-2026-90307 (8)

Same Patch Batch · Linux · 2026-09-17 · 602 CVEs total

CVE-2026-90255 Bluetooth: hci_conn: fix the SCO setup context lifetime
CVE-2026-90238 media: amd: isp4: fix self-deadlock in isp4sd_pwron_and_init() error path
CVE-2026-90240 iommu/vt-d: Flush context cache with correct SID when tearing down aliases
CVE-2026-90239 media: amd: isp4: release partial allocations in isp4if_alloc_fw_gpumem()
CVE-2026-90241 iommu/vt-d: Tear down scalable-mode context on probe failure
CVE-2026-90243 iommu/vt-d: Clear Present bit before tearing down copied context entry
CVE-2026-90242 iommu/vt-d: Fix iopf_refcount leak on RID domain replacement
CVE-2026-90244 iommu/dma: Restore locking around msi_page_list
CVE-2026-90245 fbdev: kyro: Validate overlay viewport coordinates
CVE-2026-90246 apparmor: fix integer overflow in verify_tags() bounds check
CVE-2026-90247 bpf: Fix mmap_lock leak in irq_work path
CVE-2026-90248 net/sched: cls_api: fix teardown of an adopted proto on insert-race loss
CVE-2026-90249 iio: light: gp2ap002: Fix unbalanced runtime PM on repeated event writes
CVE-2026-90250 bpf, cgroup: Fix storage null-ptr-deref after replacing prog
CVE-2026-90251 Bluetooth: MSFT: validate evt_prefix_len against the response length
CVE-2026-90253 Bluetooth: MGMT: free the mesh send cancel command when it is cancelled
CVE-2026-90252 Bluetooth: MGMT: free the HCI command when it is cancelled
CVE-2026-90254 Bluetooth: hci_sync: free the advertising instance on the failure and cancel paths
CVE-2026-90256 Bluetooth: L2CAP: use proto_lock for l2cap_data to fix l2cap_disconn_ind
CVE-2026-90268 scsi: sd: Fix error handling in sd_probe() after large pool creation failure

Showing top 20 of 602 CVEs. View all on vendor page &rarr; →

IV. Related Vulnerabilities

V. Comments for CVE-2026-90307

No comments yet


Leave a comment