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

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: <20260121080015.6aca8808.ddiss@suse.de>
Date: Wed, 21 Jan 2026 08:00:15 +1100
From: David Disseldorp <ddiss@...e.de>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Christian Brauner <brauner@...nel.org>, Petr Mladek <pmladek@...e.com>,
 linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org, Al Viro
 <viro@...iv.linux.org.uk>, Jan Kara <jack@...e.cz>, Steven Rostedt
 <rostedt@...dmis.org>, Rasmus Villemoes <linux@...musvillemoes.dk>, Sergey
 Senozhatsky <senozhatsky@...omium.org>, Andrew Morton
 <akpm@...ux-foundation.org>
Subject: Re: [PATCH v1 2/4] initramfs: Refactor to use hex2bin() instead of
 custom approach

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