All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Disseldorp <ddiss@suse.de>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Christian Brauner <brauner@kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 2/2] initramfs_test: test header fields with 0x hex prefix
Date: Thu, 22 Jan 2026 03:17:02 +1100	[thread overview]
Message-ID: <20260122031702.5e2e73c8.ddiss@suse.de> (raw)
In-Reply-To: <aXDRithD3DsGiXBc@smile.fi.intel.com>

On Wed, 21 Jan 2026 15:15:54 +0200, Andy Shevchenko wrote:

> On Wed, Jan 21, 2026 at 08:42:05PM +1100, David Disseldorp wrote:
> > On Wed, 21 Jan 2026 00:18:31 +0200, Andy Shevchenko wrote:  
> > > On Wed, Jan 21, 2026 at 07:32:33AM +1100, David Disseldorp wrote:  
> > > > cpio header fields are 8-byte hex strings, but one "interesting"
> > > > side-effect of our historic simple_str[n]toul() use means that a "0x"
> > > > prefixed header field will be successfully processed when coupled
> > > > alongside a 6-byte hex remainder string.    
> > > 
> > > Should mention that this is against specifications.

I've added this and will send as v2.

> > > > Test for this corner case by injecting "0x" prefixes into the uid, gid
> > > > and namesize cpio header fields. Confirm that init_stat() returns
> > > > matching uid and gid values.    
> > > 
> > > This is should be considered as an invalid case and I don't believe
> > > we ever had that bad header somewhere. The specification is clear
> > > that the number has to be filled with '0' to the most significant
> > > byte until all 8 positions are filled.
> > > 
> > > If any test case like this appears it should not be fatal.  
> > 
> > Yes, the test case can easily be changed to expect an unpack_to_rootfs()
> > error (or dropped completely). The purpose is just to ensure that the
> > user visible change is a concious decision rather than an undocumented
> > side effect.  
> 
> Can you say this clearly in the commit message? With that done I will have
> no objections as it seems we all agree with the possible breakage of this
> "feature" (implementation detail).

Sure, I think it'd make sense to put the v2 test patches as 1/2 in your
series such that your subsequent hex2bin() patch modifies the test to
expect error. E.g.

--- a/init/initramfs_test.c
+++ b/init/initramfs_test.c
@@ -499,8 +499,7 @@ static void __init initramfs_test_hdr_hex(struct kunit *test)
 {
        char *err, *fmt;
        size_t len;
-       struct kstat st0, st1;
-       char fdata[] = "this file data will be unpacked";
+       char fdata[] = "this file data will not be unpacked";
        struct initramfs_test_bufs {
                char cpio_src[(CPIO_HDRLEN + PATH_MAX + 3 + sizeof(fdata)) * 2];
        } *tbufs = kzalloc(sizeof(struct initramfs_test_bufs), GFP_KERNEL);
@@ -528,28 +527,14 @@ static void __init initramfs_test_hdr_hex(struct kunit *test)
        /*
         * override CPIO_HDR_FMT and instead use a format string which places
         * "0x" prefixes on the uid, gid and namesize values.
-        * parse_header()/simple_str[n]toul() accept this.
+        * parse_header()/simple_str[n]toul() accepted this, contrary to the
+        * initramfs specification. hex2bin() now fails.
         */
        fmt = "%s%08x%08x0x%06x0X%06x%08x%08x%08x%08x%08x%08x%08x0x%06x%08x%s";
        len = fill_cpio(c, ARRAY_SIZE(c), fmt, tbufs->cpio_src);
 
        err = unpack_to_rootfs(tbufs->cpio_src, len);
-       KUNIT_EXPECT_NULL(test, err);
-
-       KUNIT_EXPECT_EQ(test, init_stat(c[0].fname, &st0, 0), 0);
-       KUNIT_EXPECT_EQ(test, init_stat(c[1].fname, &st1, 0), 0);
-
-       KUNIT_EXPECT_TRUE(test,
-               uid_eq(st0.uid, make_kuid(current_user_ns(), (uid_t)0x123456)));
-       KUNIT_EXPECT_TRUE(test,
-               gid_eq(st0.gid, make_kgid(current_user_ns(), (gid_t)0x123457)));
-       KUNIT_EXPECT_TRUE(test,
-               uid_eq(st1.uid, make_kuid(current_user_ns(), (uid_t)0x56)));
-       KUNIT_EXPECT_TRUE(test,
-               gid_eq(st1.gid, make_kgid(current_user_ns(), (gid_t)0x57)));
-
-       KUNIT_EXPECT_EQ(test, init_unlink(c[0].fname), 0);
-       KUNIT_EXPECT_EQ(test, init_rmdir(c[1].fname), 0);
+       KUNIT_EXPECT_NOT_NULL(test, err);

IMO the only thing then missing is proper
hex2bin->parse_header->do_header error propagation, e.g.

--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -193,14 +193,16 @@ static __initdata gid_t gid;
 static __initdata unsigned rdev;
 static __initdata u32 hdr_csum;
 
-static void __init parse_header(char *s)
+static int __init parse_header(char *s)
 {
        __be32 header[13];
        int ret;
 
        ret = hex2bin((u8 *)header, s + 6, sizeof(header));
-       if (ret)
+       if (ret) {
                error("damaged header");
+               return ret;
+       }
 
        ino = be32_to_cpu(header[0]);
        mode = be32_to_cpu(header[1]);
@@ -214,6 +216,7 @@ static void __init parse_header(char *s)
        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]);
+       return 0;
 }
 
 /* FSM */
@@ -293,7 +296,8 @@ static int __init do_header(void)
                        error("no cpio magic");
                return 1;
        }
-       parse_header(collected);
+       if (parse_header(collected))
+               return 1;
        next_header = this_header + N_ALIGN(name_len) + body_len;
        next_header = (next_header + 3) & ~3;
        state = SkipIt;


  reply	other threads:[~2026-01-21 16:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-20 20:32 [PATCH 0/2] initramfs_test: test header fields with 0x hex prefix David Disseldorp
2026-01-20 20:32 ` [PATCH 1/2] initramfs_test: add fill_cpio() format parameter David Disseldorp
2026-01-21 13:17   ` Andy Shevchenko
2026-01-20 20:32 ` [PATCH 2/2] initramfs_test: test header fields with 0x hex prefix David Disseldorp
2026-01-20 22:18   ` Andy Shevchenko
2026-01-21  9:42     ` David Disseldorp
2026-01-21 13:15       ` Andy Shevchenko
2026-01-21 16:17         ` David Disseldorp [this message]
2026-01-21 16:30           ` Andy Shevchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260122031702.5e2e73c8.ddiss@suse.de \
    --to=ddiss@suse.de \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=brauner@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.