linux-kernel - Re: [patch -next] FMC: NULL dereference on allocation failure

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]

Message-ID: <1371665367.2038.32.camel@joe-AO722>
Date:	Wed, 19 Jun 2013 11:09:27 -0700
From:	Joe Perches <joe@...ches.com>
To:	Alessandro Rubini <rubini@...dd.com>
Cc:	dan.carpenter@...cle.com, gregkh@...uxfoundation.org,
	linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org
Subject: Re: [patch -next] FMC: NULL dereference on allocation failure

On Wed, 2013-06-19 at 19:57 +0200, Alessandro Rubini wrote:
> >> +	arr->record = kzalloc(sizeof(arr->record[0]) * n, GFP_KERNEL);
> >> +	arr->subtree = kzalloc(sizeof(arr->subtree[0]) * n, GFP_KERNEL);
> 
> > n comes from the hardware no?
> 
> Yes. Length of hardware description array.
> 
> > Maybe make these kcalloc too.
> 
> I'm not a fan of kcalloc. I think it removes readability. I remeber
> kernel patches to swap the arguments, because people get them wrong.

kcalloc's sole benefit is multiplication overflow protection.
If sizes are small and known, kcalloc isn't particularly useful.

Those kcalloc arg swap patches were just for style with no net effect.

> Even Kernighan said it was a design error (in "the practice of
> programming").  That said, I'm not the leader here.

I think the real design pattern error was realloc()

Anyway, no worries...

--
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/