[Bug 288989] A time-of-check to time-of-use (TOCTOU) race exists in the CAM Target Layer (CTL) SCSI subsystem.

[email protected] Thu, 21 Aug 2025 07:48:54 +0000
Newsgroups gmane.os.freebsd.devel.standards
Message-ID <[email protected]/bugzilla/>
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=288989

            Bug ID: 288989
           Summary: A time-of-check to time-of-use (TOCTOU) race exists in
                    the CAM Target Layer (CTL) SCSI subsystem.
           Product: Base System
           Version: 14.3-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: standards
          Assignee: [email protected]
          Reporter: [email protected]

A time-of-check to time-of-use (TOCTOU) race exists in the CAM Target
Layer (CTL) SCSI subsystem.

The maxlba field in struct ctl_be_lun can be modified at runtime.
For example, in the ramdisk backend, the ioctl path
CTL_LUN_REQ/CTL_LUNREQ_MODIFY invokes
ctl_backend_ramdisk_modify(), which can change
ctl_be_lun->maxlba. This does not synchronize with
ctl_get_lba_status() or ctl_write_same()/ctl_write_same_cont().

In ctl_get_lba_status(), a boundary check lba > lun->be_lun->maxlba
is performed, and the reply is then computed. If the LUN is shrunk after
the check, a TOCTOU race occurs: computing
lun->be_lun->maxlba + 1 - lba can wrap in unsigned arithmetic, so the
reported length may exceed the actual capacity, violating the SBC
specification and causing a semantic error.

In ctl_write_same_cont(), the code checks
(lun->be_lun->maxlba + 1) - lbalen->lba <= UINT32_MAX. If the LUN is
shrunk after this check, the subsequent computation of
(lun->be_lun->maxlba + 1) - lbalen->lba can wrap to a very large value,
and backend->config_write() is then called, potentially leading to
out-of-bounds I/O.

Suggested fix:
In ctl_get_lba_status() and ctl_write_same()/ctl_write_same_cont(),
capture the potentially changing maxlba into a local snapshot before
any bounds checks, and use that same value for all subsequent
calculations so the validated value matches the one used.

-- 
You are receiving this mail because:
You are the assignee for the bug.