On Thu, 21 Nov 2002, Bruce Allen wrote:
>> >Also, I was curious if you'd made any further progress in understanding
>> >the scsi segv problem that you were having with both smartmontools and
>> Well, I just committed a fix... that should answer both your
>> questions, I think :)
>There is something that I am confused about in your fix. The function
>that you fixed (modeselect()) is called in only one place: the function
>scsiSmartModePage1CHandler(), line 457 of scsicmds.c.
>When called the last argument of modeselect is a pointer to
>char tBuf[CDB_6_MAX_DATA_SIZE]. Yet with your modification, modeselect
>writes to this array, starting from
>and ending at tBuf[CDB_6_HDR_SIZE+CDB_6_MAX_DATA_SIZE-1].
>So it appears to me that it writes beyond the end of the array char tBuf
>Could you please help me to understand this? In the previous version of
>the code the amount of data written depended upon what was returned by
>modesense() in scsiSmartModePage1CHandler.
No, we copy _into_ the tbuf defined locally in modeselect. Which we
allocate there and then. And then we send that tBuf to the scsi device as
a command. MODE_SELECT is sending data to the device, MODE_SENSE is
reading data from it.
Let's see. We allocate an array of size 256+16 (CDB_6_MAX_DATA_SIZE +
CDB_6_HDR_SIZE) on the stack. Then, at offset 16+12 (CDB_6_HDR_SIZE +
MODE_DATA_HDR_SIZE) in the array, we copy 256-12 (CDB_6_MAX_DATA_SIZE -
As far as I can tell from simple arithmetic, no overflow of the array. And
the pbuf we read from is CDB_MAX_DATA_SIZE long, 256, allocated in
ModePage1CHandler. So no overflow on reading either, as far as I can tell.
Erik I. Bolsø | email: <knan at mo.himolde.no>
The UNIX philosophy basically involves giving you enough rope to
hang yourself. And then a couple of feet more, just to be sure.