linux-kernel - Re: [PATCH v2] virtio_blk: Fix a slient kernel panic

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:	Mon, 18 Jul 2016 18:25:34 +0200
From:	Cornelia Huck <cornelia.huck@...ibm.com>
To:	Minfei Huang <mnfhuang@...il.com>
Cc:	mst@...hat.com, virtualization@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org, fanc.fnst@...fujitsu.com,
	Minfei Huang <minfei.hmf@...baba-inc.com>
Subject: Re: [PATCH v2] virtio_blk: Fix a slient kernel panic

On Tue, 19 Jul 2016 00:18:32 +0800
Minfei Huang <mnfhuang@...il.com> wrote:

> On 07/18/16 at 05:21P, Cornelia Huck wrote:
> > On Mon, 18 Jul 2016 22:01:29 +0800
> > Minfei Huang <mnfhuang@...il.com> wrote:
> > > diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> > > index 42758b5..d920512 100644
> > > --- a/drivers/block/virtio_blk.c
> > > +++ b/drivers/block/virtio_blk.c
> > > @@ -381,9 +381,9 @@ static int init_vq(struct virtio_blk *vblk)
> > >  {
> > >  	int err = 0;
> > >  	int i;
> > > -	vq_callback_t **callbacks;
> > > -	const char **names;
> > > -	struct virtqueue **vqs;
> > > +	vq_callback_t **callbacks = NULL;
> > > +	const char **names = NULL;
> > > +	struct virtqueue **vqs = NULL;
> > 
> > If you init the variables to NULL anyway...
> 
> Hi, Cornelia.
> 
> Thanks for reviewing this patch.
> 
> Seems there is no need to init these variables to NULL. I will remove
> them laster.

Fine with me.

> 
> > 
> > >  	unsigned short num_vqs;
> > >  	struct virtio_device *vdev = vblk->vdev;
> > > 
> > > @@ -394,22 +394,16 @@ static int init_vq(struct virtio_blk *vblk)
> > >  		num_vqs = 1;
> > > 
> > 
> > ...just do
> > 
> > err = -ENOMEM;
> > 
> > here and...
> > 
> > >  	vblk->vqs = kmalloc(sizeof(*vblk->vqs) * num_vqs, GFP_KERNEL);
> > > -	if (!vblk->vqs) {
> > > -		err = -ENOMEM;
> > > -		goto out;
> > > -	}
> > > +	if (!vblk->vqs)
> > > +		return -ENOMEM;
> > > 
> > >  	names = kmalloc(sizeof(*names) * num_vqs, GFP_KERNEL);
> > > -	if (!names)
> > > -		goto err_names;
> > > -
> > >  	callbacks = kmalloc(sizeof(*callbacks) * num_vqs, GFP_KERNEL);
> > > -	if (!callbacks)
> > > -		goto err_callbacks;
> > > -
> > >  	vqs = kmalloc(sizeof(*vqs) * num_vqs, GFP_KERNEL);
> > > -	if (!vqs)
> > > -		goto err_vqs;
> > > +	if (!names || !callbacks || !vqs) {
> > > +		err = -ENOMEM;
> > > +		goto out;
> > > +	}
> > 
> > ...you could use the
> > 
> > foo = kmalloc(...);
> > if (!foo)
> > 	goto out;
> > 
> > sequence in any case. This avoids trying again and again if e.g. the
> > names allocation already failed.
> 
> For this implementation, I have referred others which calls
> vdev->config->find_vqs as well. Yes, this continues trying to allocate
> memory, although memory allocation failed before.

It might not be the best idea, though; although it should hopefully be
a not-so-common occurrence.

> 
> > 
> > Alternatively, you should be fine if you don't init the variables to
> > NULL: The code is now either taking an early exit or setting all of the
> > variables anyway.
> > 
> 
> It's a big change if we refactor the helper ->find_vqs, since other
> devices also call it.

Actually, I was referring to not initializing the variables to NULL in
this function and keeping the rest of your changes: IOW, just what you
suggested above :)