Hi Steve,
I don't think this needs to be backported to stable, since the only
place that uses the high 16 bits of the offset field as the length is
filter_pred_strloc which only works for strings and sizeof(char) == 1
so that essentially whenever the bug is triggered, the actual stored
value is
On Fri, 28 Feb 2014 21:32:16 -0800
Filipe Brandenburger wrote:
> This fixes expansion of the len argument in __dynamic_array macros.
> The previous code from commit 7d536cb3f would not fully evaluate the
> expression before multiplying its result by the size of the type.
>
> This went unnoticed
On Fri, 28 Feb 2014 21:32:16 -0800
Filipe Brandenburger filbran...@google.com wrote:
This fixes expansion of the len argument in __dynamic_array macros.
The previous code from commit 7d536cb3f would not fully evaluate the
expression before multiplying its result by the size of the type.
Hi Steve,
I don't think this needs to be backported to stable, since the only
place that uses the high 16 bits of the offset field as the length is
filter_pred_strloc which only works for strings and sizeof(char) == 1
so that essentially whenever the bug is triggered, the actual stored
value is
This fixes expansion of the len argument in __dynamic_array macros.
The previous code from commit 7d536cb3f would not fully evaluate the
expression before multiplying its result by the size of the type.
This went unnoticed because the length stored in the high 16 bits of the
offset (which is the
This fixes expansion of the len argument in __dynamic_array macros.
The previous code from commit 7d536cb3f would not fully evaluate the
expression before multiplying its result by the size of the type.
This went unnoticed because the length stored in the high 16 bits of the
offset (which is the
6 matches
Mail list logo
