[PATCH v1 0/4] initramfs: get rid of custom hex2bin()

[PATCH v1 0/4] initramfs: get rid of custom hex2bin()

[Andy Shevchenko]

The series that introduced simple_strntoul() had passed into kernel
without proper review and hence reinvented a wheel that's not needed.
Here is the refactoring to show that. This is assumed to go via PRINTK
tree.

I have tested this on x86, but I believe the same result will be
on big-endian CPUs (I deduced that from how strtox() works).

Andy Shevchenko (4):
  initramfs: Sort headers alphabetically
  initramfs: Refactor to use hex2bin() instead of custom approach
  vsprintf: Revert "add simple_strntoul"
  kstrtox: Drop extern keyword in the simple_strtox() declarations

 include/linux/kstrtox.h |  9 +++----
 init/initramfs.c        | 60 ++++++++++++++++++++++-------------------
 lib/vsprintf.c          |  7 -----
 3 files changed, 36 insertions(+), 40 deletions(-)

-- 
2.50.1

[PATCH v1 1/4] initramfs: Sort headers alphabetically

[Andy Shevchenko]

Sorting headers alphabetically helps locating duplicates, and makes it
easier to figure out where to insert new headers.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 init/initramfs.c | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/init/initramfs.c b/init/initramfs.c
index 6ddbfb17fb8f..750f126e19a0 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -1,25 +1,25 @@
 // SPDX-License-Identifier: GPL-2.0
-#include <linux/init.h>
 #include <linux/async.h>
-#include <linux/export.h>
-#include <linux/fs.h>
-#include <linux/slab.h>
-#include <linux/types.h>
-#include <linux/fcntl.h>
 #include <linux/delay.h>
-#include <linux/string.h>
 #include <linux/dirent.h>
-#include <linux/syscalls.h>
-#include <linux/utime.h>
+#include <linux/export.h>
+#include <linux/fcntl.h>
 #include <linux/file.h>
+#include <linux/fs.h>
+#include <linux/init.h>
+#include <linux/init_syscalls.h>
 #include <linux/kstrtox.h>
 #include <linux/memblock.h>
 #include <linux/mm.h>
 #include <linux/namei.h>
-#include <linux/init_syscalls.h>
-#include <linux/umh.h>
-#include <linux/security.h>
 #include <linux/overflow.h>
+#include <linux/security.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/syscalls.h>
+#include <linux/types.h>
+#include <linux/umh.h>
+#include <linux/utime.h>
 
 #include "do_mounts.h"
 #include "initramfs_internal.h"
-- 
2.50.1

[PATCH v1 2/4] initramfs: Refactor to use hex2bin() instead of custom approach

[Andy Shevchenko]

There is a simple_strntoul() function used solely as a shortcut
for hex2bin() with proper endianess conversions. Replace that
and drop the unneeded function in the next changes.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 init/initramfs.c | 36 ++++++++++++++++++++----------------
 1 file changed, 20 insertions(+), 16 deletions(-)

diff --git a/init/initramfs.c b/init/initramfs.c
index 750f126e19a0..8d931ad4d239 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -6,6 +6,7 @@
 #include <linux/fcntl.h>
 #include <linux/file.h>
 #include <linux/fs.h>
+#include <linux/hex.h>
 #include <linux/init.h>
 #include <linux/init_syscalls.h>
 #include <linux/kstrtox.h>
@@ -21,6 +22,8 @@
 #include <linux/umh.h>
 #include <linux/utime.h>
 
+#include <asm/byteorder.h>
+
 #include "do_mounts.h"
 #include "initramfs_internal.h"
 
@@ -192,24 +195,25 @@ static __initdata u32 hdr_csum;
 
 static void __init parse_header(char *s)
 {
-	unsigned long parsed[13];
-	int i;
+	__be32 header[13];
+	int ret;
 
-	for (i = 0, s += 6; i < 13; i++, s += 8)
-		parsed[i] = simple_strntoul(s, NULL, 16, 8);
+	ret = hex2bin((u8 *)header, s + 6, sizeof(header));
+	if (ret)
+		error("damaged header");
 
-	ino = parsed[0];
-	mode = parsed[1];
-	uid = parsed[2];
-	gid = parsed[3];
-	nlink = parsed[4];
-	mtime = parsed[5]; /* breaks in y2106 */
-	body_len = parsed[6];
-	major = parsed[7];
-	minor = parsed[8];
-	rdev = new_encode_dev(MKDEV(parsed[9], parsed[10]));
-	name_len = parsed[11];
-	hdr_csum = parsed[12];
+	ino = be32_to_cpu(header[0]);
+	mode = be32_to_cpu(header[1]);
+	uid = be32_to_cpu(header[2]);
+	gid = be32_to_cpu(header[3]);
+	nlink = be32_to_cpu(header[4]);
+	mtime = be32_to_cpu(header[5]); /* breaks in y2106 */
+	body_len = be32_to_cpu(header[6]);
+	major = be32_to_cpu(header[7]);
+	minor = be32_to_cpu(header[8]);
+	rdev = new_encode_dev(MKDEV(be32_to_cpu(header[9]), be32_to_cpu(header[10])));
+	name_len = be32_to_cpu(header[11]);
+	hdr_csum = be32_to_cpu(header[12]);
 }
 
 /* FSM */
-- 
2.50.1

Re: [PATCH v1 2/4] initramfs: Refactor to use hex2bin() instead of custom approach

[David Disseldorp]

On Mon, 19 Jan 2026 21:38:39 +0100, Andy Shevchenko wrote:

> +	ret = hex2bin((u8 *)header, s + 6, sizeof(header));
> +	if (ret)
> +		error("damaged header");

The changes look reasonable to me on first glance, but I think we really
should improve the error handling to abort the state machine on
malformed header here.

One further issue that we have is simple_strntoul()'s acceptance of
"0x" prefixes for the hex strings - any initramfs which carries such
prefixes will now result in an error.
It's a pretty obscure corner case, but cpio is really easy to generate
from printf(), so maybe there are some images out there which rely on
this.

I've written an initramfs_test regression test for the "0x" prefix
handling. I'll send it to the list.

Thanks, David

Re: [PATCH v1 2/4] initramfs: Refactor to use hex2bin() instead of custom approach

[Andy Shevchenko]

On Wed, Jan 21, 2026 at 07:12:50AM +1100, David Disseldorp wrote:
> On Mon, 19 Jan 2026 21:38:39 +0100, Andy Shevchenko wrote:
> 
> > +	ret = hex2bin((u8 *)header, s + 6, sizeof(header));
> > +	if (ret)
> > +		error("damaged header");
> 
> The changes look reasonable to me on first glance, but I think we really
> should improve the error handling to abort the state machine on
> malformed header here.
> 
> One further issue that we have is simple_strntoul()'s acceptance of
> "0x" prefixes for the hex strings - any initramfs which carries such
> prefixes will now result in an error.
> It's a pretty obscure corner case, but cpio is really easy to generate
> from printf(), so maybe there are some images out there which rely on
> this.
> 
> I've written an initramfs_test regression test for the "0x" prefix
> handling. I'll send it to the list.

Is it specified?

The standard refers to octal numbers, we seem to use hexadecimal.
I don't believe the 0x will ever appear here.

Otherwise, please point out to the specifications.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 2/4] initramfs: Refactor to use hex2bin() instead of custom approach

[David Disseldorp]

On Tue, 20 Jan 2026 22:34:45 +0200, Andy Shevchenko wrote:

> On Wed, Jan 21, 2026 at 07:12:50AM +1100, David Disseldorp wrote:
> > On Mon, 19 Jan 2026 21:38:39 +0100, Andy Shevchenko wrote:
> >   
> > > +	ret = hex2bin((u8 *)header, s + 6, sizeof(header));
> > > +	if (ret)
> > > +		error("damaged header");  
> > 
> > The changes look reasonable to me on first glance, but I think we really
> > should improve the error handling to abort the state machine on
> > malformed header here.
> > 
> > One further issue that we have is simple_strntoul()'s acceptance of
> > "0x" prefixes for the hex strings - any initramfs which carries such
> > prefixes will now result in an error.
> > It's a pretty obscure corner case, but cpio is really easy to generate
> > from printf(), so maybe there are some images out there which rely on
> > this.
> > 
> > I've written an initramfs_test regression test for the "0x" prefix
> > handling. I'll send it to the list.  
> 
> Is it specified?
> 
> The standard refers to octal numbers, we seem to use hexadecimal.
> I don't believe the 0x will ever appear here.
> 
> Otherwise, please point out to the specifications.

The kernel initramfs specification is at
Documentation/driver-api/early-userspace/buffer-format.rst :

  The structure of the cpio_header is as follows (all fields contain
  hexadecimal ASCII numbers fully padded with '0' on the left to the
  full width of the field, for example, the integer 4780 is represented
  by the ASCII string "000012ac"):
  ...

I.e. a "0x" isn't specified as valid prefix. I don't feel strongly
regarding diverging from existing behaviour, but it should still be
considered (and documented) as a potentially user-visible regression.

Cheers, David

Re: [PATCH v1 2/4] initramfs: Refactor to use hex2bin() instead of custom approach

[Andy Shevchenko]

On Wed, Jan 21, 2026 at 08:00:15AM +1100, David Disseldorp wrote:
> On Tue, 20 Jan 2026 22:34:45 +0200, Andy Shevchenko wrote:
> > On Wed, Jan 21, 2026 at 07:12:50AM +1100, David Disseldorp wrote:
> > > On Mon, 19 Jan 2026 21:38:39 +0100, Andy Shevchenko wrote:

...

> > > > +	ret = hex2bin((u8 *)header, s + 6, sizeof(header));
> > > > +	if (ret)
> > > > +		error("damaged header");  
> > > 
> > > The changes look reasonable to me on first glance, but I think we really
> > > should improve the error handling to abort the state machine on
> > > malformed header here.
> > > 
> > > One further issue that we have is simple_strntoul()'s acceptance of
> > > "0x" prefixes for the hex strings - any initramfs which carries such
> > > prefixes will now result in an error.
> > > It's a pretty obscure corner case, but cpio is really easy to generate
> > > from printf(), so maybe there are some images out there which rely on
> > > this.
> > > 
> > > I've written an initramfs_test regression test for the "0x" prefix
> > > handling. I'll send it to the list.  
> > 
> > Is it specified?
> > 
> > The standard refers to octal numbers, we seem to use hexadecimal.
> > I don't believe the 0x will ever appear here.
> > 
> > Otherwise, please point out to the specifications.
> 
> The kernel initramfs specification is at
> Documentation/driver-api/early-userspace/buffer-format.rst :

Thanks!

>   The structure of the cpio_header is as follows (all fields contain
>   hexadecimal ASCII numbers fully padded with '0' on the left to the
>   full width of the field, for example, the integer 4780 is represented
>   by the ASCII string "000012ac"):
>   ...
> 
> I.e. a "0x" isn't specified as valid prefix. I don't feel strongly
> regarding diverging from existing behaviour,

> but it should still be
> considered (and documented) as a potentially user-visible regression.

I disagree, this is not specified and should not be used. The CPIO archive in
the original form doesn't specify leading 0 for octals (at least how I read it,
please correct me, if I'm wrong).

https://pubs.opengroup.org/onlinepubs/007908799/xcu/pax.html

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 2/4] initramfs: Refactor to use hex2bin() instead of custom approach

[H. Peter Anvin]

On 2026-01-20 13:17, Andy Shevchenko wrote:
>>
>> I.e. a "0x" isn't specified as valid prefix. I don't feel strongly
>> regarding diverging from existing behaviour,
> 
>> but it should still be
>> considered (and documented) as a potentially user-visible regression.
> 
> I disagree, this is not specified and should not be used. The CPIO archive in
> the original form doesn't specify leading 0 for octals (at least how I read it,
> please correct me, if I'm wrong).
> 
> https://pubs.opengroup.org/onlinepubs/007908799/xcu/pax.html
> 

This is the "newc" or "crc" format used by BSD (header magic 070701 and
070702, respectively), those were never standardized by POSIX.

These formats use 8-character hexadecimal (%08x).

As far as a 0x prefix, or upper case -- no, that is technically not according
to spec, but we DO NOT break user space tools that have been working for 20+
years, unless it is either (a) a security problem or (b) is holding back
further development (e.g. because the format is ambiguous. This is Postel's
law in action.

	-hpa

[PATCH v1 3/4] vsprintf: Revert "add simple_strntoul"

[Andy Shevchenko]

No users anymore and none should be in the first place.

This reverts commit fcc155008a20fa31b01569e105250490750f0687.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 include/linux/kstrtox.h | 1 -
 lib/vsprintf.c          | 7 -------
 2 files changed, 8 deletions(-)

diff --git a/include/linux/kstrtox.h b/include/linux/kstrtox.h
index 6ea897222af1..7fcf29a4e0de 100644
--- a/include/linux/kstrtox.h
+++ b/include/linux/kstrtox.h
@@ -143,7 +143,6 @@ static inline int __must_check kstrtos32_from_user(const char __user *s, size_t
  */
 
 extern unsigned long simple_strtoul(const char *,char **,unsigned int);
-extern unsigned long simple_strntoul(const char *,char **,unsigned int,size_t);
 extern long simple_strtol(const char *,char **,unsigned int);
 extern unsigned long long simple_strtoull(const char *,char **,unsigned int);
 extern long long simple_strtoll(const char *,char **,unsigned int);
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 800b8ac49f53..52ea14a08d3a 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -129,13 +129,6 @@ unsigned long simple_strtoul(const char *cp, char **endp, unsigned int base)
 }
 EXPORT_SYMBOL(simple_strtoul);
 
-unsigned long simple_strntoul(const char *cp, char **endp, unsigned int base,
-			      size_t max_chars)
-{
-	return simple_strntoull(cp, endp, base, max_chars);
-}
-EXPORT_SYMBOL(simple_strntoul);
-
 /**
  * simple_strtol - convert a string to a signed long
  * @cp: The start of the string
-- 
2.50.1

[PATCH v1 4/4] kstrtox: Drop extern keyword in the simple_strtox() declarations

[Andy Shevchenko]

There is legacy 'extern' keyword for the exported simple_strtox()
function which are the artefact that can be removed. So drop it.

While at it, tweak the declaration to provide parameter names.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 include/linux/kstrtox.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/linux/kstrtox.h b/include/linux/kstrtox.h
index 7fcf29a4e0de..6c9282866770 100644
--- a/include/linux/kstrtox.h
+++ b/include/linux/kstrtox.h
@@ -142,9 +142,9 @@ static inline int __must_check kstrtos32_from_user(const char __user *s, size_t
  * Keep in mind above caveat.
  */
 
-extern unsigned long simple_strtoul(const char *,char **,unsigned int);
-extern long simple_strtol(const char *,char **,unsigned int);
-extern unsigned long long simple_strtoull(const char *,char **,unsigned int);
-extern long long simple_strtoll(const char *,char **,unsigned int);
+unsigned long simple_strtoul(const char *cp, char **endp, unsigned int base);
+long simple_strtol(const char *cp, char **endp, unsigned int base);
+unsigned long long simple_strtoull(const char *cp, char **endp, unsigned int base);
+long long simple_strtoll(const char *cp, char **endp, unsigned int base);
 
 #endif	/* _LINUX_KSTRTOX_H */
-- 
2.50.1

Re: [PATCH v1 0/4] initramfs: get rid of custom hex2bin()

[Christian Brauner]

> Here is the refactoring to show that. This is assumed to go via PRINTK
> tree.

No, initramfs is maintained by the VFS and we already carry other patches.

If you want the kstrtox changes to go another route then I will take the
first two changes in a stable branch that can be merged.

> 
> I have tested this on x86, but I believe the same result will be
> on big-endian CPUs (I deduced that from how strtox() works).

Did you rerun the kunit tests the original change was part of or did you
do some custom testing?

Re: [PATCH v1 0/4] initramfs: get rid of custom hex2bin()

[Andy Shevchenko]

On Tue, Jan 20, 2026 at 12:20:41PM +0100, Christian Brauner wrote:
> > Here is the refactoring to show that. This is assumed to go via PRINTK
> > tree.
> 
> No, initramfs is maintained by the VFS and we already carry other patches.

If this applies cleanly, take them through it, I will be glad, thanks!

> If you want the kstrtox changes to go another route then I will take the
> first two changes in a stable branch that can be merged.

I am fine with this route as long as the custom approach is gone.

> > I have tested this on x86, but I believe the same result will be
> > on big-endian CPUs (I deduced that from how strtox() works).
> 
> Did you rerun the kunit tests the original change was part of or did you
> do some custom testing?

I'm not sure I understand the point. There were no test cases added for
simple_strntoul() AFAICS. Did I miss anything?

(If I didn't that is the second point on why the patches didn't get enough
 time for review and not every stakeholder seen them, usually we require
 the test cases for new APIs.)

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 0/4] initramfs: get rid of custom hex2bin()

[Christian Brauner]

On Tue, Jan 20, 2026 at 02:46:54PM +0200, Andy Shevchenko wrote:
> On Tue, Jan 20, 2026 at 12:20:41PM +0100, Christian Brauner wrote:
> > > Here is the refactoring to show that. This is assumed to go via PRINTK
> > > tree.
> > 
> > No, initramfs is maintained by the VFS and we already carry other patches.
> 
> If this applies cleanly, take them through it, I will be glad, thanks!
> 
> > If you want the kstrtox changes to go another route then I will take the
> > first two changes in a stable branch that can be merged.
> 
> I am fine with this route as long as the custom approach is gone.
> 
> > > I have tested this on x86, but I believe the same result will be
> > > on big-endian CPUs (I deduced that from how strtox() works).
> > 
> > Did you rerun the kunit tests the original change was part of or did you
> > do some custom testing?
> 
> I'm not sure I understand the point. There were no test cases added for
> simple_strntoul() AFAICS. Did I miss anything?
> 
> (If I didn't that is the second point on why the patches didn't get enough
>  time for review and not every stakeholder seen them, usually we require
>  the test cases for new APIs.)

Sorry, I meant the kunit tests that do test the initramfs unpacking.

Re: [PATCH v1 0/4] initramfs: get rid of custom hex2bin()

[Andy Shevchenko]

On Fri, Jan 23, 2026 at 01:22:44PM +0100, Christian Brauner wrote:
> On Tue, Jan 20, 2026 at 02:46:54PM +0200, Andy Shevchenko wrote:
> > On Tue, Jan 20, 2026 at 12:20:41PM +0100, Christian Brauner wrote:
> > > > Here is the refactoring to show that. This is assumed to go via PRINTK
> > > > tree.

> > > No, initramfs is maintained by the VFS and we already carry other patches.
> > 
> > If this applies cleanly, take them through it, I will be glad, thanks!
> > 
> > > If you want the kstrtox changes to go another route then I will take the
> > > first two changes in a stable branch that can be merged.
> > 
> > I am fine with this route as long as the custom approach is gone.
> > 
> > > > I have tested this on x86, but I believe the same result will be
> > > > on big-endian CPUs (I deduced that from how strtox() works).
> > > 
> > > Did you rerun the kunit tests the original change was part of or did you
> > > do some custom testing?
> > 
> > I'm not sure I understand the point. There were no test cases added for
> > simple_strntoul() AFAICS. Did I miss anything?
> > 
> > (If I didn't that is the second point on why the patches didn't get enough
> >  time for review and not every stakeholder seen them, usually we require
> >  the test cases for new APIs.)
> 
> Sorry, I meant the kunit tests that do test the initramfs unpacking.

Nope, I run on the real HW with real initramfs and I saw the difference when
code was under development (not working). The version I sent works good. But
noted, next time I will run also above mentioned test cases, thanks for
pointing that out.

-- 
With Best Regards,
Andy Shevchenko