From: Dan Carpenter <dan.carpenter@linaro.org>
To: Su Hui <suhui@nfschina.com>
Cc: sj@kernel.org, akpm@linux-foundation.org, damon@lists.linux.dev,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
kernel-janitors@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH] mm/damon/sysfs-schemes: using kmalloc_array() and size_add()
Date: Tue, 22 Apr 2025 13:38:05 +0300 [thread overview]
Message-ID: <2713f419-760b-4ccc-aeed-de9c4c899506@stanley.mountain> (raw)
In-Reply-To: <20250421062423.740605-1-suhui@nfschina.com>
On Mon, Apr 21, 2025 at 02:24:24PM +0800, Su Hui wrote:
> It's safer to using kmalloc_array() and size_add() because it can
> prevent possible overflow problem.
>
> Signed-off-by: Su Hui <suhui@nfschina.com>
> ---
> mm/damon/sysfs-schemes.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/mm/damon/sysfs-schemes.c b/mm/damon/sysfs-schemes.c
> index 23b562df0839..79220aba436f 100644
> --- a/mm/damon/sysfs-schemes.c
> +++ b/mm/damon/sysfs-schemes.c
> @@ -465,7 +465,8 @@ static ssize_t memcg_path_store(struct kobject *kobj,
> {
> struct damon_sysfs_scheme_filter *filter = container_of(kobj,
> struct damon_sysfs_scheme_filter, kobj);
> - char *path = kmalloc(sizeof(*path) * (count + 1), GFP_KERNEL);
> + char *path = kmalloc_array(size_add(count, 1), sizeof(*path),
> + GFP_KERNEL);
Count is clamped in rw_verify_area().
Smatch does a kind of ugly hack to handle rw_verify_area() which is that
it says neither the count nor the pos can be more than 1G. And obviously
files which are larger than 2GB exist but pretending they don't silences
all these integer overflow warnings.
>
> if (!path)
> return -ENOMEM;
> @@ -2035,7 +2036,7 @@ static int damon_sysfs_memcg_path_to_id(char *memcg_path, unsigned short *id)
> if (!memcg_path)
> return -EINVAL;
>
> - path = kmalloc(sizeof(*path) * PATH_MAX, GFP_KERNEL);
> + path = kmalloc_array(PATH_MAX, sizeof(*path), GFP_KERNEL);
If we boost PATH_MAX to that high then we're going to run into
all sorts of other issues first.
regards,
dan carpenter
next prev parent reply other threads:[~2025-04-22 10:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20250421062423.740605-1-suhui@nfschina.com>
2025-04-21 17:07 ` SeongJae Park
2025-04-22 10:38 ` Dan Carpenter [this message]
2025-04-22 10:44 ` Dan Carpenter
2025-04-22 18:23 ` SeongJae Park
2025-04-22 18:50 ` Christophe JAILLET
[not found] ` <21407408-78e4-48eb-8296-fcddc702ae25@nfschina.com>
2025-04-23 5:38 ` Dan Carpenter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2713f419-760b-4ccc-aeed-de9c4c899506@stanley.mountain \
--to=dan.carpenter@linaro.org \
--cc=akpm@linux-foundation.org \
--cc=damon@lists.linux.dev \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=sj@kernel.org \
--cc=suhui@nfschina.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox