This patch fixes a NULL dereference introduced by
commit e407a7f6cd143b3ab4eb3d7e1cf882e96b710eb5:
This quite unusual error handling through a switch introduces NULL
dereferences if exactly one of the two k{c,z}alloc's failed.
That wouldn't be unfixable, but considering that the Linux kernel is not
part of the obfuscated C contest (and silent fallthroughs in switches do
not improve readability) I've converted it to a normal error handling.
The NULL dereference was spotted by the Coverity checker.
Signed-off-by: Adrian Bunk <[email protected]>
---
drivers/block/aoe/aoedev.c | 46 ++++++++++++++++++-------------------
1 file changed, 23 insertions(+), 23 deletions(-)
--- linux-2.6/drivers/block/aoe/aoedev.c.old 2006-10-31 23:56:46.000000000 +0100
+++ linux-2.6/drivers/block/aoe/aoedev.c 2006-11-01 00:23:49.000000000 +0100
@@ -64,30 +64,25 @@
d = kzalloc(sizeof *d, GFP_ATOMIC);
f = kcalloc(nframes, sizeof *f, GFP_ATOMIC);
- switch (!d || !f) {
- case 0:
- d->nframes = nframes;
- d->frames = f;
- e = f + nframes;
- for (; f<e; f++) {
- f->tag = FREETAG;
- f->skb = new_skb(ETH_ZLEN);
- if (!f->skb)
- break;
- }
- if (f == e)
- break;
- while (f > d->frames) {
- f--;
- dev_kfree_skb(f->skb);
- }
- default:
- if (f)
- kfree(f);
- if (d)
- kfree(d);
- return NULL;
+
+ if (!d || !f)
+ goto out_err;
+
+ d->nframes = nframes;
+ d->frames = f;
+ e = f + nframes;
+ for (; f < e; f++) {
+ f->tag = FREETAG;
+ f->skb = new_skb(ETH_ZLEN);
+ if (!f->skb) {
+ while (f > d->frames) {
+ f--;
+ dev_kfree_skb(f->skb);
+ }
+ goto out_err;
+ }
}
+
INIT_WORK(&d->work, aoecmd_sleepwork, d);
spin_lock_init(&d->lock);
init_timer(&d->timer);
@@ -101,6 +96,11 @@
devlist = d;
return d;
+
+out_err:
+ kfree(f);
+ kfree(d);
+ return NULL;
}
void
On Wed, Nov 01, 2006 at 01:40:25AM +0100, Adrian Bunk wrote:
> This patch fixes a NULL dereference introduced by
> commit e407a7f6cd143b3ab4eb3d7e1cf882e96b710eb5:
>
> This quite unusual error handling through a switch introduces NULL
> dereferences if exactly one of the two k{c,z}alloc's failed.
Hmm. If exactly one of the two fails, then the value of the switch
conditional is 1 (well, certainly not zero). It will jump over the
zero case, and there's a return in the default case, so I'm having
trouble seeing the danger.
What exactly is Coverity saying? That would be interesting to know.
--
Ed L Cashin <[email protected]>
On Wed, Nov 01, 2006 at 11:36:28AM -0500, Ed L. Cashin wrote:
> On Wed, Nov 01, 2006 at 01:40:25AM +0100, Adrian Bunk wrote:
> > This patch fixes a NULL dereference introduced by
> > commit e407a7f6cd143b3ab4eb3d7e1cf882e96b710eb5:
> >
> > This quite unusual error handling through a switch introduces NULL
> > dereferences if exactly one of the two k{c,z}alloc's failed.
>
> Hmm. If exactly one of the two fails, then the value of the switch
> conditional is 1 (well, certainly not zero). It will jump over the
> zero case, and there's a return in the default case, so I'm having
> trouble seeing the danger.
>
> What exactly is Coverity saying? That would be interesting to know.
The Coverity checker was wrong in this case, and I didn't spot it when
checking since the code is really confusing.
> Ed L Cashin <[email protected]>
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed