[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACAyw99bEYWJCSGqfLiJ9Jp5YE1ZsZSiJxb4RFUTwbofipf0dA@mail.gmail.com>
Date: Tue, 26 Jan 2021 09:36:57 +0000
From: Lorenz Bauer <lmb@...udflare.com>
To: Bui Quang Minh <minhquangbui99@...il.com>
Cc: Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
"David S . Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>, hawk@...nel.org,
John Fastabend <john.fastabend@...il.com>,
Andrii Nakryiko <andrii@...nel.org>, Martin Lau <kafai@...com>,
Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
kpsingh@...nel.org, Jakub Sitnicki <jakub@...udflare.com>,
Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] bpf: Fix integer overflow in argument calculation for bpf_map_area_alloc
On Tue, 26 Jan 2021 at 08:26, Bui Quang Minh <minhquangbui99@...il.com> 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 memory than needed.
>
> Fix this by casting 1 operand to u64.
Some quick thoughts:
* Should this have a Fixes tag?
* Seems like there are quite a few similar calls scattered around
(cpumap, etc.). Did you audit these as well?
* I'd prefer a calloc style version of bpf_map_area_alloc although
that might conflict with Fixes tag.
Lorenz
--
Lorenz Bauer | Systems Engineer
6th Floor, County Hall/The Riverside Building, SE1 7PB, UK
www.cloudflare.com
Powered by blists - more mailing lists