In the Linux kernel, the following vulnerability has been resolved: scsi: libiscsi_tcp: Check the…

Why it is Amber

• CVSS 7.5 high
• Remotely exploitable without logging in
• On your watchlist: linux kernel

References

• https://git.kernel.org/stable/c/24ffc919467d20951f0f132d1c75294e2e91e09b
• https://git.kernel.org/stable/c/79991b770fc3685b1d5cf805b659a879edd19931
• https://git.kernel.org/stable/c/8db1232945bc663fb94f300090a1fc108de99296
• https://git.kernel.org/stable/c/94e5bdd08e51c450d954bc592f591c233ca5c9df
• https://git.kernel.org/stable/c/bce07e2f37b5e4a427d36fd6b1c14067b27591db
• https://git.kernel.org/stable/c/de96dc11aee0d058927bff94a168e3c5c46483e2
• https://git.kernel.org/stable/c/e3b25bf2cf2496e85bc05b33360faf9fdf880e03
• https://git.kernel.org/stable/c/ee56b5e18f566c0b5a183379dcd63d402cebf2f8

Original description

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.