linux-kernel - Re: [PATCH] lib: string_helpers: fix potential snprintf() output truncation

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <87y12gp7xb.fsf@prevas.dk>
Date: Tue, 22 Oct 2024 15:46:08 +0200
From: Rasmus Villemoes <ravi@...vas.dk>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: Jiri Slaby <jirislaby@...nel.org>,  Bartosz Golaszewski <brgl@...ev.pl>,
  Kees Cook <kees@...nel.org>,  Andy Shevchenko <andy@...nel.org>,  Andrew
 Morton <akpm@...ux-foundation.org>,  James Bottomley
 <James.Bottomley@...senpartnership.com>,  Greg KH
 <gregkh@...uxfoundation.org>,  linux-hardening@...r.kernel.org,
  linux-kernel@...r.kernel.org,  Bartosz Golaszewski
 <bartosz.golaszewski@...aro.org>,  stable@...r.kernel.org
Subject: Re: [PATCH] lib: string_helpers: fix potential snprintf() output
 truncation

On Tue, Oct 22 2024, Andy Shevchenko <andy.shevchenko@...il.com> wrote:

> On Tue, Oct 22, 2024 at 10:15 AM Jiri Slaby <jirislaby@...nel.org> wrote:
>>
>> On 21. 10. 24, 12:04, Bartosz Golaszewski wrote:
>> > From: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
>> >
>> > The output of ".%03u" with the unsigned int in range [0, 4294966295] may
>> > get truncated if the target buffer is not 12 bytes.
>>
>> Perhaps, if you elaborate on how 'remainder' can become > 999?
>
> The problem here that we have a two-way road: on one hand we ought to
> fix the bugs in the kernel, on the other hand the compiler warnings
> (even false positives) better to be fixed as we don't know which
> compiler gets it fixed, but now we have a problem with building with
> `make W=1` for the default configurations (it prevents build due to
> compilation errors), so this change is definitely is an improvement.

Well, yes, kind of, and of course a 12 byte stack buffer doesn't hurt
more than an 8 byte one (i.e. not at all). However, it does feel rather
arbitrary.

Can't we fix the code to avoid the tmp buffer and do one less
snprintf()? Something like this entirely untested thing:

diff --git a/lib/string_helpers.c b/lib/string_helpers.c
index 9982344cca34..7aa592f9a494 100644
--- a/lib/string_helpers.c
+++ b/lib/string_helpers.c
@@ -50,13 +50,10 @@ void string_get_size(u64 size, u64 blk_size, const enum string_size_units units,
 		[STRING_UNITS_2] = 1024,
 	};
 	static const unsigned int rounding[] = { 500, 50, 5 };
-	int i = 0, j;
+	int i = 0, j = 0;
 	u32 remainder = 0, sf_cap;
-	char tmp[8];
 	const char *unit;
 
-	tmp[0] = '\0';
-
 	if (blk_size == 0)
 		size = 0;
 	if (size == 0)
@@ -115,19 +112,16 @@ void string_get_size(u64 size, u64 blk_size, const enum string_size_units units,
 		size += 1;
 	}
 
-	if (j) {
-		snprintf(tmp, sizeof(tmp), ".%03u", remainder);
-		tmp[j+1] = '\0';
-	}
-
  out:
 	if (i >= ARRAY_SIZE(units_2))
 		unit = "UNK";
 	else
 		unit = units_str[units][i];
 
-	snprintf(buf, len, "%u%s %s", (u32)size,
-		 tmp, unit);
+	if (j)
+		snprintf(buf, len, "%u.%03u %s", (u32)size, remainder, unit);
+	else
+		snprintf(buf, len, "%u %s", (u32)size, unit);
 }
 EXPORT_SYMBOL(string_get_size);
 
Rasmus