| Message ID | 20190430131946.26628-1-brogers@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] scsi-disk: handle invalid cdb length | expand |
On 4/30/19 9:19 AM, Bruce Rogers wrote: > While investigating link-time-optimization, the compiler flagged this > case of not handling the error return from scsi_cdb_length(). Handle > this error case with a trace report. > > Signed-off-by: Bruce Rogers <brogers@suse.com> > --- > hw/scsi/scsi-disk.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c > index e7e865ab3b..8fbf7512e5 100644 > --- a/hw/scsi/scsi-disk.c > +++ b/hw/scsi/scsi-disk.c > @@ -2520,6 +2520,10 @@ static void scsi_disk_new_request_dump(uint32_t lun, uint32_t tag, uint8_t *buf) > int len = scsi_cdb_length(buf); > char *line_buffer, *p; > > + if (len < 0) { > + trace_scsi_disk_new_request(lun, tag, "bad cdb length"); This is going to print: "Command: lun=%d tag=0x%x data=bad cdb length" which is maybe not the best. I'd rather print something more direct, but it's probably better than actually rolling forward with len = -1. Then again, this should literally never happen, because scsi_req_new is parsing the cdb object and already rejecting such cases. Can you satisfy the compiler by asserting that it is greater than zero? It ought to be provably true. --js > + return; > + } > line_buffer = g_malloc(len * 5 + 1); > > for (i = 0, p = line_buffer; i < len; i++) { >
>>> On 4/30/2019 at 2:40 PM, John Snow <jsnow@redhat.com> wrote: > > On 4/30/19 9:19 AM, Bruce Rogers wrote: >> While investigating link-time-optimization, the compiler flagged this >> case of not handling the error return from scsi_cdb_length(). Handle >> this error case with a trace report. >> >> Signed-off-by: Bruce Rogers <brogers@suse.com> >> --- >> hw/scsi/scsi-disk.c | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c >> index e7e865ab3b..8fbf7512e5 100644 >> --- a/hw/scsi/scsi-disk.c >> +++ b/hw/scsi/scsi-disk.c >> @@ -2520,6 +2520,10 @@ static void scsi_disk_new_request_dump(uint32_t lun, > uint32_t tag, uint8_t *buf) >> int len = scsi_cdb_length(buf); >> char *line_buffer, *p; >> >> + if (len < 0) { >> + trace_scsi_disk_new_request(lun, tag, "bad cdb length"); > > This is going to print: > > "Command: lun=%d tag=0x%x data=bad cdb length" > > which is maybe not the best. I'd rather print something more direct, but > it's probably better than actually rolling forward with len = -1. > > Then again, this should literally never happen, because scsi_req_new is > parsing the cdb object and already rejecting such cases. > Indeed, that is true. > Can you satisfy the compiler by asserting that it is greater than zero? > It ought to be provably true. Yes, that seems to work and is probably the way to go. I'll send a patch with that approach then. Thanks for the review. > > --js > >> + return; >> + } >> line_buffer = g_malloc(len * 5 + 1); >> >> for (i = 0, p = line_buffer; i < len; i++) { >> Bruce
diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c index e7e865ab3b..8fbf7512e5 100644 --- a/hw/scsi/scsi-disk.c +++ b/hw/scsi/scsi-disk.c @@ -2520,6 +2520,10 @@ static void scsi_disk_new_request_dump(uint32_t lun, uint32_t tag, uint8_t *buf) int len = scsi_cdb_length(buf); char *line_buffer, *p; + if (len < 0) { + trace_scsi_disk_new_request(lun, tag, "bad cdb length"); + return; + } line_buffer = g_malloc(len * 5 + 1); for (i = 0, p = line_buffer; i < len; i++) {
While investigating link-time-optimization, the compiler flagged this case of not handling the error return from scsi_cdb_length(). Handle this error case with a trace report. Signed-off-by: Bruce Rogers <brogers@suse.com> --- hw/scsi/scsi-disk.c | 4 ++++ 1 file changed, 4 insertions(+)