scsi: target: iscsi: Reserve a terminator byte for the login payload
Affects Linux kernel iSCSI target portals configured for CHAP authentication. Fixed in kernel stable releases 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.51 and 7.2.5, and later.
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Unclear
- Fix
- Fixed in 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, and 2 more
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
The Linux kernel's iSCSI target login handling is affected. A remote, unauthenticated initiator sending an oversized login request to a CHAP-configured portal could cause the kernel to read past the end of a buffer that lacks a string terminator, potentially exposing or corrupting adjacent kernel memory.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Reserve a terminator byte for the login payload iscsi_target_check_login_request() rejects a login PDU whose DataSegmentLength exceeds MAX_KEY_VALUE_PAIRS, but the test is '>' and login->req_buf is allocated with exactly MAX_KEY_VALUE_PAIRS bytes. Since iscsit_get_login_rx() receives payload_length + padding bytes, where padding = ((-payload_length) & 3); any payload_length from 8189 to 8192 fills the whole 8192 byte buffer. The write stays in bounds, but no byte is left for a NUL terminator. The buffer is subsequently consumed as a C string. In the CHAP path chap_check_algorithm() calls kstrdup(a_str), and extract_param() calls strstr(in_buf, pattern) followed by strlen_semi(), none of which take a length. convert_null_to_semi() additionally rewrites every embedded NUL to ';', so even a payload made of well formed NUL separated key=value records is left without a terminator. These walk past the end of the object into adjacent slab memory. It is reachable by an unauthenticated initiator against a portal configured for CHAP; when authentication is not required iscsi_login_zero_tsih_s2() rewrites AuthMethod to None and the CHAP path is never entered. Allocate one extra byte. kzalloc() zeroes it and nothing ever writes to it, as every writer copies to offset 0 for at most MAX_KEY_VALUE_PAIRS bytes, so the buffer is always terminated.
Timeline
- CVE published
- Record last updated
Affected versions
- Linux Linux
From e48354ce078c079996f89d715dfa44814b4eba01 · fixed in 5fac79f248c37774d1dd761406f83d25ca6ff8e4; From e48354ce078c079996f89d715dfa44814b4eba01 · fixed in 6ddddcad436d8e6e619204d3c848147ff2f5bf1e; From e48354ce078c079996f89d715dfa44814b4eba01 · fixed in b19dc17ed963ac36c0db4b52a1803fb11169f91f; From e48354ce078c079996f89d715dfa44814b4eba01 · fixed in 6b589ef9d5f6cdc70d2b4f269ca6cf26b5ebb076; From e48354ce078c079996f89d715dfa44814b4eba01 · fixed in eb9dadf4d552ebe10644871c5189286552aa48f5; From e48354ce078c079996f89d715dfa44814b4eba01 · fixed in 1624bff4c5118ad494d50ad94d44f22064667a7f; From e48354ce078c079996f89d715dfa44814b4eba01 · fixed in 3ddf3ea291a0ef2ea93b82e158960ac2cc42302b; From e48354ce078c079996f89d715dfa44814b4eba01 · fixed in f4825922d2fb371e2b969697d792077f1b62b62c
- Linux Linux
3.1
- KernelLinux
From 3.1.0 · fixed in 5.10.270; From 5.11.0 · fixed in 5.15.221; From 5.16.0 · fixed in 6.1.188; From 6.2.0 · fixed in 6.6.157; From 6.7.0 · fixed in 6.12.110; From 6.13.0 · fixed in 6.18.51; From 6.19.0 · fixed in 7.2.5
References 8
git.kernel.org
- stable/c/5fac79f248c37774d1dd761406f83d25ca6ff8e4
- stable/c/6ddddcad436d8e6e619204d3c848147ff2f5bf1e
- stable/c/b19dc17ed963ac36c0db4b52a1803fb11169f91f
- stable/c/6b589ef9d5f6cdc70d2b4f269ca6cf26b5ebb076
- stable/c/eb9dadf4d552ebe10644871c5189286552aa48f5
- stable/c/1624bff4c5118ad494d50ad94d44f22064667a7f
- stable/c/3ddf3ea291a0ef2ea93b82e158960ac2cc42302b
- stable/c/f4825922d2fb371e2b969697d792077f1b62b62c
Questions about CVE-2026-90011
What does this mean?
When a CHAP login payload is between 8189 and 8192 bytes, it fills the whole 8192-byte buffer and leaves no terminator byte. The kernel then handles that buffer as a C string, so it can read past the end into adjacent slab memory.Source: git.kernel.org
Am I affected, and how do I check?
The affected range starts at kernel 3.1.0 and runs up to the first fixed release on each branch: 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.51 and 7.2.5. Check the running kernel with uname -r, and check whether the iSCSI target portal is configured for CHAP authentication.Source: git.kernel.org
What should I do about it?
Upgrade to the fixed stable kernel for your branch: 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.51, or 7.2.5 or later.Source: git.kernel.org
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data