Re: [PING 2] [PATCH] c++/67942 - diagnose placement new buffer overflow

[Jason Merrill <jason@redhat.com>]

On 11/04/2015 12:11 PM, Martin Sebor wrote:
> On 11/02/2015 07:40 PM, Jason Merrill wrote:
>> On 10/26/2015 09:48 PM, Martin Sebor wrote:
>>> +  while (TREE_CODE (oper) == NOP_EXPR)
>>> +    oper = TREE_OPERAND (oper, 0);
>>
>> This is STRIP_NOPS.
>>
>>> +     to placement new is not checked since it's unknownwhat it might
>>
>> Missing space.
>>
>>> +  else if (TREE_CODE (oper) == ADDR_EXPR) {
>>
>> The brace should go on its own line.
>>
>>> +      /* A possibly optimistic estimate Number of bytes available
>>
>> Maybe "of the number"?
>
> Thanks for the review. I've fixed the issues above in the latest
> patch (attached).
>
>>
>>> +      /* When the referenced object is a member of a union, use the
>>> size
>>> +     of the entire union as the size of the buffer.  */
>>
>> Why?  If we're accessing one union member, we should limit the allowed
>> space to the size of that member.
>
> I followed the more permissive approach taken by _FORTIFY_SOURCE
> where the size of the whole object is used (on the assumption that
> we will eventually want to adopt the same mechanism here). For
> instance, given:
>
>    union U { char c; int i; } u;
>
> GCC doesn't diagnose:
>
>    memset (&u.c, 0, sizeof u);
>
> so I didn't expect we'd want the following diagnosed either:
>
>    new (&u.c) U ();
>
> But if you think it's preferable to use the size of the member
> for this iteration of the placement new warning I can change it.
> Can you confirm?

There was a lot of discussion of C++ aliasing rules at the recent 
meeting; we really seem to be moving in the direction of being stricter 
about which union member is active.  So I think we do want to diagnose 
the new-expression above; the user should write new (&u) if that's what 
they mean.

>>> +      if (bytes_avail <= abs (adjust))
>>> +    bytes_avail = 0;
>>> +      else if (0 <= adjust)
>>> +    bytes_avail -= adjust;
>>> +      else
>>> +    bytes_avail += adjust;
>>
>> If adjust is negative, I would think that we would have returned already
>> because we were dealing with an offset from a pointer of unknown value.
>
> Adjust is negative when the offset to a buffer of known size is
> negative. For example:
>
>      char buf [sizeof (int)];
>      new (&buf [1] - 1) int;

OK, so because we're looking at the expression from the outside in, we 
first see the subtraction and adjust becomes -1, then we see the 
array_ref and adjust returns to 0.  We still don't have a negative 
adjust by the time we get to the quoted if/else.

>> It also seems that you're being careful to avoid bytes_avail going
>> negative, so I wonder why you have it signed and bytes_need unsigned.
>>
>>> +          warning_at (EXPR_LOC_OR_LOC (orig_oper, input_location),
>>
>> Let's remember this location early on so you don't need orig_oper.
>
> Done.
>
> Martin