CVE-2026-72084: scsi: target: Bound PR-OUT TransportID parsing to the received buffer

Published Aug 15, 2026
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

scsi: target: Bound PR-OUT TransportID parsing to the received buffer

corescsi3decodespeciport() and corescsi3emulateregisterandmove() hand the raw PERSISTENT RESERVE OUT parameter buffer to targetparseprouttransportid() without telling it how many bytes are valid. For an iSCSI TransportID (FORMAT CODE 01b), iscsiparseprouttransportid() locates the ",i,0x" ISID separator with an unbounded strstr() (and on the error path prints the name with a further unbounded "%s"). An initiator can submit a TransportID whose iSCSI name contains neither a ",i,0x" substring nor a NUL terminator, filling the parameter list to its end, so the scan runs off the end of the buffer.

When the parameter list spans more than one page the buffer is a multi-page vmap (transportkmapdatasg()), so the over-read walks into the trailing vmalloc guard page and oopses (KASAN: vmalloc-out-of-bounds in strstr). It is reachable by any fabric that delivers a PR OUT to a device exported through an iSCSI TPG, including a guest via vhost-scsi.

Pass the number of received bytes down to the parser and validate the iSCSI TransportID's own self-described length (ADDITIONAL LENGTH + 4) once, up front: reject it if it is below the spc4r17 minimum or larger than the received buffer, then bound the separator search, the ISID walk and the name copy by that length. This is the length check the callers already perform after the parse (corescsi3decodespeciport() compares tidlen against tpdl, corescsi3emulateregisterandmove() validates it against datalength), moved ahead of the scan. Also drop the unbounded "%s" of the unterminated name.

Add per-format explicit name-length checks before copying into istr, rather than silently truncating with mint: for FORMAT CODE 00b reject if the descriptor body (tidlen - 4 bytes) cannot fit in istr[TRANSPORTIQNLEN]; for FORMAT CODE 01b reject if the name portion (from &buf[4] up to the separator) cannot fit. Both checks make the bounds intent explicit at each format branch.

While here, also reject a FORMAT CODE 01b TransportID whose ",i,0x" separator sits at the very end of the descriptor: that leaves an empty ISID and points the returned port nexus pointer at buf + tidlen, one past the descriptor, which the registration code (corescsi3locateprreg(), corescsi3allocregistration()) then dereferences as the ISID string -- the same over-read of the parameter buffer for a malformed descriptor.

Affected Software

1 affected component
Linux Linux kernel

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Configuration

    Apply the kernel fix referenced by the resolved vulnerability: pass the received byte count to the iSCSI TransportID parser, validate iSCSI TransportID self-described length against the received buffer (ADDITIONAL LENGTH + 4) before copying, bound the search for the ',i,0x' separator and the ISID/name scan to the received buffer, replace unbounded '%s' usage with length-bounded handling, and reject malformed FORMAT CODE 01b/00b TransportID descriptors (including empty ISID when separator is at descriptor end and unterminated ISID strings without NUL).

    Linux kernel iSCSI PR-OUT TransportID parsing (scsi target) Bound parsing of iSCSI TransportID FORMAT CODE 00b / 01b to the received buffer length; reject empty/unterminated ISID name; bound separator search and replace unbounded strstr()/printf %s usage = Apply the resolved bounds checks: pass received byte count to parser; validate self-described TransportID length against (ADDITIONAL LENGTH + 4) using bounds; for FORMAT CODE 01b reject TransportID with missing separator/bad name (no NUL terminator / no ',i,0x') and reject name that cannot fit; for FORMAT CODE 00b reject if received buffer is too short to include full descriptor body; avoid over-read into vmalloc trailing page

Event History

Aug 15, 2026
CVE Published
via MITRE·05:52 AM
Data Sourced
via MITRE·05:52 AM
Description
Data Sourced
via NVD·06:21 AM
Description
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2026-72084?

CVE-2026-72084 has a risk rating of 65, indicating a moderate level of severity.

2

What software is affected by CVE-2026-72084?

CVE-2026-72084 affects the Linux kernel.

3

How do I fix CVE-2026-72084?

To fix CVE-2026-72084, you should update to the latest version of the Linux kernel that includes the security patch.

4

What are the consequences of CVE-2026-72084 if left unaddressed?

If left unaddressed, CVE-2026-72084 could potentially allow attackers to exploit vulnerabilities related to SCSI TransportID parsing.

5

When was CVE-2026-72084 published?

CVE-2026-72084 was published on August 15, 2026.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203