Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1438247 > unrolled thread

[PATCH] xen-blkfront: avoid NULL de-reference in CDROM ioctl handling

Back to article view | Back to linux.kernel

Contents

  [PATCH] xen-blkfront: avoid NULL de-reference in CDROM ioctl  handling "Jan Beulich" <JBeulich@suse.com> - 2016-07-07 09:50 +0200
    Re: [PATCH] xen-blkfront: avoid NULL de-reference in CDROM ioctl  handling Roger Pau Monne <roger.pau@citrix.com> - 2016-07-07 11:40 +0200
      Re: [PATCH] xen-blkfront: avoid NULL de-reference in CDROM  ioctl handling "Jan Beulich" <JBeulich@suse.com> - 2016-07-07 11:50 +0200
        Re: [PATCH] xen-blkfront: avoid NULL de-reference in CDROM ioctl  handling Roger Pau Monne <roger.pau@citrix.com> - 2016-07-07 13:00 +0200

#1438247 — [PATCH] xen-blkfront: avoid NULL de-reference in CDROM ioctl handling

The ioctl can be called prior to full device setup having completed.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
 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))
 			return 0;
 		return -EINVAL;
-	}
 
 	default:
 		/*printk(KERN_ALERT "ioctl %08x not supported by Xen blkdev\n",

[toc] | [next] | [standalone]

#1438441

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@suse.com>
> ---
>  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.

Roger.

[toc] | [prev] | [next] | [standalone]

#1438471 — Re: [PATCH] xen-blkfront: avoid NULL de-reference in CDROM ioctl handling

>>> On 07.07.16 at 11:32, <roger.pau@citrix.com> 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@suse.com>
>> ---
>>  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

[toc] | [prev] | [next] | [standalone]

#1438520

On Thu, Jul 07, 2016 at 03:42:02AM -0600, Jan Beulich wrote:
> >>> On 07.07.16 at 11:32, <roger.pau@citrix.com> 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@suse.com>
> >> ---
> >>  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.

I agree that it looks like 2.6.18 has the same flow, so that info->gd cannot 
be NULL if the ioctl handler is called, but without anyone having reported 
any issue and blkfront code being in upstream Linux for quite a long time 
I'm reluctant to take this, even more without a trace that shows the actual 
bug.

Roger.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web