linux-kernel - [PATCH v4 1/4] kstrtox: always skip the leading "0x" even if no more valid chars

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: <9076fa9d3d2d3b2574386f4850a45f7902f6503c.1704422015.git.wqu@suse.com>
Date: Fri,  5 Jan 2024 13:04:59 +1030
From: Qu Wenruo <wqu@...e.com>
To: linux-btrfs@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org,
	christophe.jaillet@...adoo.fr,
	andriy.shevchenko@...ux.intel.com,
	David.Laight@...LAB.COM,
	ddiss@...e.de,
	geert@...ux-m68k.org,
	rdunlap@...radead.org
Subject: [PATCH v4 1/4] kstrtox: always skip the leading "0x" even if no more valid chars

Currently the invalid string "0x" (only hex prefix, no valid chars
followed) would make _parse_integer_fixup_radix() to treat it as octal.

This is due to the fact that the function would only auto-detect hex if
and only if there is any valid hex char after "0x".
Or it would only go octal instead.

Thankfully this won't affect our unit test, as "0x" would still be
treated as failure (-EINVAL) anyway:

- Old code treats "0x" as '0' with tailing 'x'
  Thus return -EINVAL due to the tailing 'x'.

- New code treats "0x" as "0x" suffix with nothing following up
  Thus return -EINVAL due to no valid string.

But for the incoming memparse_safe(), the remaining string would still
be consumed by the caller, and we need to properly treat "0x" as an
invalid string.

So this patch would make _parse_integer_fixup_radix() to forcefully go
hex no matter if there is any valid char following.

And there is a also copy of _parse_integer_fixup_radix() inside
arch/x86/boot/string.c, to keep the code consistent this patch would
also modify that copy.

Thankfully for that copy in arch/x86/boot/string.c, it's only doing
kstrtoll(), thus there would be no behavior change, just as explained
above.

Signed-off-by: Qu Wenruo <wqu@...e.com>
Reviewed-by: David Disseldorp <ddiss@...e.de>
---
 arch/x86/boot/string.c | 2 +-
 lib/kstrtox.c          | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/boot/string.c b/arch/x86/boot/string.c
index 1c8541ae3b3a..49750ef697bb 100644
--- a/arch/x86/boot/string.c
+++ b/arch/x86/boot/string.c
@@ -233,7 +233,7 @@ static const char *_parse_integer_fixup_radix(const char *s, unsigned int *base)
 {
 	if (*base == 0) {
 		if (s[0] == '0') {
-			if (_tolower(s[1]) == 'x' && isxdigit(s[2]))
+			if (_tolower(s[1]) == 'x')
 				*base = 16;
 			else
 				*base = 8;
diff --git a/lib/kstrtox.c b/lib/kstrtox.c
index d586e6af5e5a..41c9a499bbf3 100644
--- a/lib/kstrtox.c
+++ b/lib/kstrtox.c
@@ -27,7 +27,7 @@ const char *_parse_integer_fixup_radix(const char *s, unsigned int *base)
 {
 	if (*base == 0) {
 		if (s[0] == '0') {
-			if (_tolower(s[1]) == 'x' && isxdigit(s[2]))
+			if (_tolower(s[1]) == 'x')
 				*base = 16;
 			else
 				*base = 8;
-- 
2.43.0