On Tue, 6 May 2014, David Chisnall wrote:
On 6 May 2014, at 05:46, Bruce Evans wrote:
The standard behaviour is undefined. It cannot be relied on. From C99
(n869.txt):
%7.20.3.1 The calloc function
% %Synopsis
% %[#1]
% %#include
%v
Bruce,
On 6 May 2014, at 05:46, Bruce Evans wrote:
> The standard behaviour is undefined. It cannot be relied on. From C99
> (n869.txt):
>
> %7.20.3.1 The calloc function
> % %Synopsis
> % %[#1]
> % %#include
> %void *calloc(size_t nme
On Tue, 6 May 2014, Andrey Chernov wrote:
On 06.05.2014 2:12, David Chisnall wrote:
On 5 May 2014, at 22:51, Andrey Chernov wrote:
For standard malloc/realloc interface it is up to the caller to check
n*size not overflows. You must trust caller already does such check.
Do a search of the C
On Tue, 6 May 2014, Andrey Chernov wrote:
On 05.05.2014 22:28, David Chisnall wrote:
On 5 May 2014, at 18:42, Andrey Chernov wrote:
Please don't commit OpenBSD errors. Now you mix calloc() with the
realloc() for the same variable later which makes calloc() zeroing
pointless and waste of CPU.
On 06.05.2014 2:59, Warner Losh wrote:
> Stupid is as stupid does. malloc and realloc both have this same issue. While
> an interesting theoretical attack, the size doesn’t necessarily come from
> multiplication. Careful coding is still required, not matter what spin you
> put on this. reallocf(
On 06.05.2014 2:52, Andrey Chernov wrote:
> As I mention initially, literal enough checks is what we need to make
> logic clear. In the case we discuss realloc() can be changed by
> reallocf() which does n*size and NULL checks and literal "if" should be
> added before malloc() to check overflow.
S
On May 5, 2014, at 3:43 PM, David Chisnall wrote:
> On 5 May 2014, at 22:33, Warner Losh wrote:
>
>> reallocf():
>>The reallocf() function is identical to the realloc() function, except
>>that it will free the passed pointer when the requested memory cannot be
>>allocated. This is
On 06.05.2014 2:12, David Chisnall wrote:
> On 5 May 2014, at 22:51, Andrey Chernov wrote:
>
>> For standard malloc/realloc interface it is up to the caller to check
>> n*size not overflows. You must trust caller already does such check.
>
> Do a search of the CVE database sometime to see how we
On May 5, 2014, at 4:10 PM, Pedro Giffuni wrote:
> El 5/5/2014 4:21 PM, David Chisnall escribió:
>> On 5 May 2014, at 20:49, Pedro Giffuni wrote:
>>
>>> Yes, but I reverted it because there are other ways to check for overflows
>>> without the performance hit.
>>
>
> FWIW, in this particula
El 5/5/2014 4:21 PM, David Chisnall escribió:
On 5 May 2014, at 20:49, Pedro Giffuni wrote:
Yes, but I reverted it because there are other ways to check for overflows
without the performance hit.
FWIW, in this particular case I think the overflow simply doesn't
happen: apparently it is e
On 5 May 2014, at 22:51, Andrey Chernov wrote:
> For standard malloc/realloc interface it is up to the caller to check
> n*size not overflows. You must trust caller already does such check.
Do a search of the CVE database sometime to see how well placed that trust
generally is. Or even look at
On 06.05.2014 1:52, David Chisnall wrote:
> This is not relying on undocumented intrinsic knowledge, this is relying on
> the standard library doing what is required of it. There is a reason why
> secure coding standards have, for over a decade, said to prefer calloc() over
> malloc() unless pr
On 5 May 2014, at 22:40, Andrey Chernov wrote:
> On 05.05.2014 22:28, David Chisnall wrote:
>> On 5 May 2014, at 18:42, Andrey Chernov wrote:
>>
>>> Please don't commit OpenBSD errors. Now you mix calloc() with the
>>> realloc() for the same variable later which makes calloc() zeroing
>>> point
On 06.05.2014 1:43, David Chisnall wrote:
> While reallocf() is nice, it doesn't address the problem of overflow. It
> takes a single size, forcing the caller to do the number-of-elements *
> element-size multiplication, which is the problematic one. If an attacker
> can control the number of
On 5 May 2014, at 22:33, Warner Losh wrote:
> reallocf():
> The reallocf() function is identical to the realloc() function, except
> that it will free the passed pointer when the requested memory cannot be
> allocated. This is a FreeBSD specific API designed to ease the problems
>
On 05.05.2014 22:28, David Chisnall wrote:
> On 5 May 2014, at 18:42, Andrey Chernov wrote:
>
>> Please don't commit OpenBSD errors. Now you mix calloc() with the
>> realloc() for the same variable later which makes calloc() zeroing
>> pointless and waste of CPU.
>
> The purpose of calloc() here
On May 5, 2014, at 3:21 PM, David Chisnall wrote:
> On 5 May 2014, at 20:49, Pedro Giffuni wrote:
>
>> Yes, but I reverted it because there are other ways to check for overflows
>> without the performance hit.
>
> Do we have a good reusable routine for doing this somewhere? Clang and gcc
>
On 5 May 2014, at 20:49, Pedro Giffuni wrote:
> Yes, but I reverted it because there are other ways to check for overflows
> without the performance hit.
Do we have a good reusable routine for doing this somewhere? Clang and gcc
both have some idiom recognisers that try to spot when people ar
El 5/5/2014 1:28 PM, David Chisnall escribió:
On 5 May 2014, at 18:42, Andrey Chernov wrote:
Please don't commit OpenBSD errors. Now you mix calloc() with the
realloc() for the same variable later which makes calloc() zeroing
pointless and waste of CPU.
The purpose of calloc() here is not (p
On 5 May 2014, at 18:42, Andrey Chernov wrote:
> Please don't commit OpenBSD errors. Now you mix calloc() with the
> realloc() for the same variable later which makes calloc() zeroing
> pointless and waste of CPU.
The purpose of calloc() here is not (primarily) to get the zero'd size, it's to
g
On 05.05.2014 20:41, Pedro F. Giffuni wrote:
> Log:
> regex: Use calloc instead of malloc.
>
> Mostly to reduce differences with OpenBSD.
Please don't commit OpenBSD errors. Now you mix calloc() with the
realloc() for the same variable later which makes calloc() zeroing
pointless and waste
Author: pfg
Date: Mon May 5 16:41:15 2014
New Revision: 265367
URL: http://svnweb.freebsd.org/changeset/base/265367
Log:
regex: Use calloc instead of malloc.
Mostly to reduce differences with OpenBSD.
Obtained from:OpenBSD (CVS rev. 1.17)
MFC after:3 days
Modified:
he
22 matches
Mail list logo
