CVE-2026-90307 Affecting kernel-livepatch-6_4_0-150700_7_78-rt package, versions <1-150700.1.3.1
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-SLES157-KERNELLIVEPATCH640150700778RT-20936175
- published14 Oct 2026
- disclosed13 Oct 2026
Introduced: 13 Oct 2026
NewCVE-2026-90307 (opens in a new tab)How to fix?
Upgrade SLES:15.7 kernel-livepatch-6_4_0-150700_7_78-rt to version 1-150700.1.3.1 or higher.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-livepatch-6_4_0-150700_7_78-rt package and not the kernel-livepatch-6_4_0-150700_7_78-rt package as distributed by SLES.
See How to fix? for SLES:15.7 relevant fixed versions and status.
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.
References
- https://www.suse.com/security/cve/CVE-2026-90307.html
- https://bugzilla.suse.com/1282050
- https://git.kernel.org/stable/c/001adf2fe87d1ab677c014a97467bbea5153ae5f
- https://git.kernel.org/stable/c/0e7ba617514902501514d577647d866e670dad90
- https://git.kernel.org/stable/c/138eb2f0ef02adfe6ad126afad5b54c56b5046ee
- https://git.kernel.org/stable/c/3787f4c3e0d813d6c56be9f6dfaf66f8551fb0a7
- https://git.kernel.org/stable/c/3f7fdf561f1ec3b523c39708df00bd808671668d
- https://git.kernel.org/stable/c/961ac0f0c5e414abdd6b33fae84b311d9fde0bd0
- https://git.kernel.org/stable/c/dc2272c00d7c00ee2a69b57f7ca9caaefcbdb8cd
- https://git.kernel.org/stable/c/fa1b33fdab3e79dce83721ead3220200a2dbec22