On 1/27/21 5:23 AM, Bui Quang Minh wrote:
On Tue, Jan 26, 2021 at 09:36:57AM +, Lorenz Bauer wrote:
On Tue, 26 Jan 2021 at 08:26, Bui Quang Minh wrote:
In 32-bit architecture, the result of sizeof() is a 32-bit integer so
the expression becomes the multiplication between 2 32-bit integer
On Wed, Jan 27, 2021 at 11:23:41AM +0700, Bui Quang Minh wrote:
> > * Seems like there are quite a few similar calls scattered around
> > (cpumap, etc.). Did you audit these as well?
>
> I spotted another bug after re-auditting. In hashtab, there ares 2 places
> using
> the same calls
>
>
On Tue, Jan 26, 2021 at 09:36:57AM +, Lorenz Bauer wrote:
> On Tue, 26 Jan 2021 at 08:26, Bui Quang Minh wrote:
> >
> > In 32-bit architecture, the result of sizeof() is a 32-bit integer so
> > the expression becomes the multiplication between 2 32-bit integer which
> > can potentially leads t
On Tue, 26 Jan 2021 at 08:26, Bui Quang Minh wrote:
>
> In 32-bit architecture, the result of sizeof() is a 32-bit integer so
> the expression becomes the multiplication between 2 32-bit integer which
> can potentially leads to integer overflow. As a result,
> bpf_map_area_alloc() allocates less m
In 32-bit architecture, the result of sizeof() is a 32-bit integer so
the expression becomes the multiplication between 2 32-bit integer which
can potentially leads to integer overflow. As a result,
bpf_map_area_alloc() allocates less memory than needed.
Fix this by casting 1 operand to u64.
Sign
