[Bug 215474] ccb_pathinq.(sim_vid|hba_vid|dev_name) aren't null terminated

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Wed Dec 21 18:07:50 UTC 2016


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215474

            Bug ID: 215474
           Summary: ccb_pathinq.(sim_vid|hba_vid|dev_name) aren't null
                    terminated
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: asomers at FreeBSD.org

The sim_vid, hba_vid, and dev_name fields of struct ccb_pathinq are
fixed-length strings.  AFAICT the only place they're read is in
sbin/camcontrol/camcontrol.c, which assumes they'll be null-terminated. 
However, the kernel doesn't null-terminate them. A bunch of copy-pasted code
uses strncpy to write them, and doesn't guarantee null-termination.  For at
least 4 drivers (mpr, mps, ciss, and hyperv), the hba_vid field actually
overflows.  You can see the result by doing "camcontrol negotiate da0 -v". 
Note the garbage at the end of the HBA vendor field:

$ camcontrol negotiate da0 -v
Current parameters:
(pass0:mps0:0:10:0): transfer speed: 300.000MB/s
(pass0:mps0:0:10:0): tagged queueing: enabled
mps0: SIM/HBA version: 1
mps0: supports tag queue messages
mps0: supports SDTR message
mps0: supports 16 bit wide SCSI
mps0: unknown PIM bit set
mps0: unknown PIM bit set
mps0: user has disabled initial BUS RESET or controller is in target/mixed mode
mps0: HBA engine count: 0
mps0: maximum target: 255
mps0: maximum LUN: 255
mps0: highest path ID in subsystem: 0
mps0: initiator ID: 255
mps0: SIM vendor: FreeBSD
mps0: HBA vendor: Avago Tech (LSI)mps
mps0: HBA vendor ID: 0x0000
mps0: HBA device ID: 0x0000
mps0: HBA subvendor ID: 0x0000
mps0: HBA subdevice ID: 0x0000
mps0: bus ID: 0
mps0: base transfer speed: 150.000MB/sec
mps0: maximum transfer size: 4722688 bytes

The correct solution is to replace strncpy with strlcpy to null-terminate them,
and shorten the hard-coded strings that are too long.

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


More information about the freebsd-bugs mailing list