linux-kernel - Re: [PATCH] staging: rtl8712: fix potential leak in r871x_wx_set_enc

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] [day] [month] [year] [list]

Message-ID: <1399971676.3703.21.camel@smile.fi.intel.com>
Date:	Tue, 13 May 2014 12:01:16 +0300
From:	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:	Dan Carpenter <dan.carpenter@...cle.com>
Cc:	Christian Engelmayer <cengelma@....at>, devel@...verdev.osuosl.org,
	florian.c.schilhabel@...glemail.com, gregkh@...uxfoundation.org,
	linux-kernel@...r.kernel.org, paul.gortmaker@...driver.com,
	linuxgeek@...il.com, Larry.Finger@...inger.net
Subject: Re: [PATCH] staging: rtl8712: fix potential leak in
 r871x_wx_set_enc_ext()


On Wed, 2014-05-07 at 11:55 +0300, Dan Carpenter wrote:
> On Wed, May 07, 2014 at 09:55:47AM +0300, Andy Shevchenko wrote:
> > > @@ -1824,6 +1817,15 @@ static int r871x_wx_set_enc_ext(struct net_device *dev,
> > >  	default:
> > >  		return -EINVAL;
> > >  	}
> > > +
> > > +	param_len = sizeof(struct ieee_param) + pext->key_len;
> > > +	param = (struct ieee_param *)_malloc(param_len);
> > 
> > While you are here could you substitute _malloc by kzalloc and remove
> > explicit casting and memset?
> > 
> 
> Normally, that's the kind of thing we would do in a separate patch
> because or the "one thing per patch" rule.  Eventually someone will do a
> driver wide replacement of _malloc().  Or if the bug fixer wanted, he
> could do it in this patch because it is on the same line and all so it
> counts as a "minor closely related change."  Either way is fine.
> 
> Another way to say this is that since the _malloc() was there in the
> original code and Christian didn't introduce it, then we shouldn't
> reject his patch because of it.  This is staging code, and there are so
> many problems that if you start trying to fix everything you'll just get
> lost.
> 
> In my experience v2 patches are much harder to write than v1 patches.
> Twice in the past few days I have messed up the subject line in my v2
> patches.

I'm not objecting to let green light for it, indeed maybe someone could
change all _mallocs & memsets in that code.

-- 
Andy Shevchenko <andriy.shevchenko@...el.com>
Intel Finland Oy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/