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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 07 Jul 2016 03:42:02 -0600
From:	"Jan Beulich" <JBeulich@...e.com>
To:	"Roger Pau Monne" <roger.pau@...rix.com>
Cc:	<xen-devel@...ts.xenproject.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@...cle.com>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] xen-blkfront: avoid NULL de-reference in CDROM
 ioctl handling

>>> On 07.07.16 at 11:32, <roger.pau@...rix.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@...e.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