On Wed, May 23, 2018 at 02:17:14PM -0700, Kees Cook wrote: > > True, though I'm finding other robustness issues in the CDROM code. > They're probably all insane corner cases, but it seems like it'd be > nice to just fix them: > > diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c > index 3522d2cae1b6..7726c8618c30 100644 > --- a/drivers/cdrom/cdrom.c > +++ b/drivers/cdrom/cdrom.c > @@ -2222,9 +2223,12 @@ static int cdrom_read_cdda_bpc(struct > cdrom_device_info *cdi, __u8 __user *ubuf, > > blk_execute_rq(q, cdi->disk, rq, 0); > if (scsi_req(rq)->result) { > - struct request_sense *s = req->sense; > + struct scsi_sense_hdr sshdr; > + > ret = -EIO; > - cdi->last_sense = s->sense_key; > + scsi_normalize_sense(req->sense, req->sense_len, > + &sshdr); > + cdi->last_sense = sshdr.sense_key; > } > > if (blk_rq_unmap_user(bio)) The proper fix here is to rewrite this function to use the the ->generic_packet cdrom_device_ops method. Is is the only caller going straight to the scsi passthrough requests, which is a layering violation.