scsi: libiscsi_tcp: Check the data direction of a Data-In PDU
- 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
- Fix
- Fixed in 5.10.271, 5.15.222, 6.1.189, 6.6.158, 6.12.112, 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
In the Linux kernel, the following vulnerability has been resolved: scsi: libiscsi_tcp: Check the data direction of a Data-In PDU The Data-In branch of iscsi_tcp_hdr_dissect() resolves the ITT to a task and copies the PDU's data segment into that command's scatterlist without asking whether the command was reading. iscsi_tcp_r2t_rsp() in the same file does ask, and rejects an R2T for a command that is not DMA_TO_DEVICE. A target that answers a WRITE command's ITT with a Data-In therefore has the initiator write target-supplied bytes into the pages that write was about to send. Those are the caller's own pinned pages for an O_DIRECT write, and page cache pages for a buffered one. Observed against a test target that emits one 512-byte Data-In naming a 128 KB write's ITT, after the R2T for that write. With O_DIRECT the caller's buffer ends up holding 512 bytes of the target's data while pwrite() returns 131072. Buffered is quieter: pwrite() and fsync() both succeed, nothing is logged, and reading those blocks back returns the target's bytes out of the page cache without a command going on the wire. Check the direction before using the scatterlist, the way the R2T path already does.
Timeline
- CVE published
- Record last updated
Affected versions
- Linux Linux
From a081c13e39b5c17052a7b46fafa61019c4c110ff · fixed in 79991b770fc3685b1d5cf805b659a879edd19931; From a081c13e39b5c17052a7b46fafa61019c4c110ff · fixed in 8db1232945bc663fb94f300090a1fc108de99296; From a081c13e39b5c17052a7b46fafa61019c4c110ff · fixed in 94e5bdd08e51c450d954bc592f591c233ca5c9df; From a081c13e39b5c17052a7b46fafa61019c4c110ff · fixed in de96dc11aee0d058927bff94a168e3c5c46483e2; From a081c13e39b5c17052a7b46fafa61019c4c110ff · fixed in e3b25bf2cf2496e85bc05b33360faf9fdf880e03; From a081c13e39b5c17052a7b46fafa61019c4c110ff · fixed in ee56b5e18f566c0b5a183379dcd63d402cebf2f8; From a081c13e39b5c17052a7b46fafa61019c4c110ff · fixed in 24ffc919467d20951f0f132d1c75294e2e91e09b; From a081c13e39b5c17052a7b46fafa61019c4c110ff · fixed in bce07e2f37b5e4a427d36fd6b1c14067b27591db
- Linux Linux
2.6.29
- KernelLinux
From 2.6.29 · fixed in 5.10.271; From 5.11.0 · fixed in 5.15.222; From 5.16.0 · fixed in 6.1.189; From 6.2.0 · fixed in 6.6.158; From 6.7.0 · fixed in 6.12.112; From 6.13.0 · fixed in 6.18.55; From 6.19.0 · fixed in 7.2.9
References 8
git.kernel.org
- stable/c/79991b770fc3685b1d5cf805b659a879edd19931
- stable/c/8db1232945bc663fb94f300090a1fc108de99296
- stable/c/94e5bdd08e51c450d954bc592f591c233ca5c9df
- stable/c/de96dc11aee0d058927bff94a168e3c5c46483e2
- stable/c/e3b25bf2cf2496e85bc05b33360faf9fdf880e03
- stable/c/ee56b5e18f566c0b5a183379dcd63d402cebf2f8
- stable/c/24ffc919467d20951f0f132d1c75294e2e91e09b
- stable/c/bce07e2f37b5e4a427d36fd6b1c14067b27591db