[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] xen-blkfront: avoid NULL de-reference in CDROM ioctl handling
>>> On 07.07.16 at 11:32, <roger.pau@xxxxxxxxxx> wrote: > On Thu, Jul 07, 2016 at 01:40:54AM -0600, Jan Beulich wrote: >> The ioctl can be called prior to full device setup having completed. >> >> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> >> --- >> drivers/block/xen-blkfront.c | 6 ++---- >> 1 file changed, 2 insertions(+), 4 deletions(-) >> >> --- 4.7-rc6-xen.orig/drivers/block/xen-blkfront.c >> +++ 4.7-rc6-xen/drivers/block/xen-blkfront.c >> @@ -496,12 +496,10 @@ static int blkif_ioctl(struct block_devi >> return -EFAULT; >> return 0; >> >> - case CDROM_GET_CAPABILITY: { >> - struct gendisk *gd = info->gd; >> - if (gd->flags & GENHD_FL_CD) >> + case CDROM_GET_CAPABILITY: >> + if (info->gd && (info->gd->flags & GENHD_FL_CD)) > > I don't follow how blkif_ioctl can be called with a NULL info->gd, because > the set of file operations is set inside of info->gd->fops. And the disk > should not be available until add_disk is called, which happens after having > info->gd already set. Well, this (as many of the other patches sent earlier today) is a result of me finally doing a sweep over the old 2.6.18 tree to see which changes never made it upstream. This is one of them. Hence I can't entirely exclude that the issue cannot be observed on a modern kernel (for whatever reason), but it surely was observed years ago on that old kernel. The sequence of events in xlvbd_alloc_gendisk() alone certainly leaves room for this, but I agree that the call to add_disk() _should_ be a prereq to getting into blkif_ioctl() and definitely only happens after xlvbd_alloc_gendisk() completed. But I guess you agree that this _should_ should also have applied to 2.6.18. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |