linux-kernel - Re: [PATCH] mm/damon/dbgfs: fix bogus string length

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Fri,  2 Feb 2024 09:14:02 -0800
From: SeongJae Park <sj@...nel.org>
To: Arnd Bergmann <arnd@...nel.org>
Cc: SeongJae Park <sj@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	damon@...ts.linux.dev,
	linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm/damon/dbgfs: fix bogus string length

Hi Arnd,

On Fri,  2 Feb 2024 13:43:26 +0100 Arnd Bergmann <arnd@...nel.org> wrote:

> From: Arnd Bergmann <arnd@...db.de>
> 
> gcc correctly points out that using strnlen() on a fixed size array
> is nonsense with an overlong limit:
> 
> mm/damon/dbgfs.c: In function 'damon_dbgfs_deprecated_read':
> mm/damon/dbgfs.c:814:19: error: 'strnlen' specified bound 1024 exceeds source size 512 [-Werror=stringop-overread]
>   814 |         int len = strnlen(kbuf, 1024);
>       |                   ^~~~~~~~~~~~~~~~~~~
> mm/damon/dbgfs.c:813:14: note: source object allocated here
>   813 |         char kbuf[512] = DAMON_DBGFS_DEPRECATION_NOTICE;
>       |              ^~~~
> 
> In fact, neither of the arbitrary limits are needed here: The first
> one can just be a static const string and avoid wasting any more
> space then necessary, and the strnlen() can be either strlen() or
> sizeof(kbuf)-1, both of which the compiler turns into the same
> constant here.

Thank you for this fix!

> 
> Fixes: adf9047adfff ("mm/damon/dbgfs: implement deprecation notice file")
> Signed-off-by: Arnd Bergmann <arnd@...db.de>

Reviewed-by: SeongJae Park <sj@...nel.org>


Thanks,
SJ

[...]