linux-kernel - Re: ext4_mballoc_test: Internal error: Oops: map_id_range_down (kernel/user

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: <20240229-stapfen-eistee-9d946b4a3a9d@brauner>
Date: Thu, 29 Feb 2024 11:09:24 +0100
From: Christian Brauner <brauner@...nel.org>
To: Guenter Roeck <linux@...ck-us.net>
Cc: Daniel Díaz <daniel.diaz@...aro.org>, 
	Naresh Kamboju <naresh.kamboju@...aro.org>, open list <linux-kernel@...r.kernel.org>, 
	linux-ext4 <linux-ext4@...r.kernel.org>, linux-fsdevel@...r.kernel.org, lkft-triage@...ts.linaro.org, 
	Jan Kara <jack@...e.cz>, Andreas Dilger <adilger.kernel@...ger.ca>, 
	Theodore Ts'o <tytso@....edu>, Randy Dunlap <rdunlap@...radead.org>, shikemeng@...weicloud.com, 
	Arnd Bergmann <arnd@...db.de>, Dan Carpenter <dan.carpenter@...aro.org>
Subject: Re: ext4_mballoc_test: Internal error: Oops: map_id_range_down
 (kernel/user_namespace.c:318)

On Wed, Feb 28, 2024 at 11:33:36AM -0800, Guenter Roeck wrote:
> On 2/28/24 11:26, Daniel Díaz wrote:
> > Hello!
> > 
> > On Wed, 28 Feb 2024 at 12:19, Naresh Kamboju <naresh.kamboju@...aro.org> wrote:
> > > Kunit ext4_mballoc_test tests found following kernel oops on Linux next.
> > > All ways reproducible on all the architectures and steps to reproduce shared
> > > in the bottom of this email.
> > > 
> > > Reported-by: Linux Kernel Functional Testing <lkft@...aro.org>
> > > 
> 
> [ ... ]
> 
> > +Guenter. Just the thing we were talking about, at about the same time.
> > 
> 
> Good that others see the same problem. Thanks a lot for reporting!

Hm...

static struct super_block *mbt_ext4_alloc_super_block(void)
{                                                                                                                                                                                                       struct ext4_super_block *es = kzalloc(sizeof(*es), GFP_KERNEL);
        struct ext4_sb_info *sbi = kzalloc(sizeof(*sbi), GFP_KERNEL);
        struct mbt_ext4_super_block *fsb = kzalloc(sizeof(*fsb), GFP_KERNEL);

        if (fsb == NULL || sbi == NULL || es == NULL)
                goto out;

        sbi->s_es = es;
        fsb->sb.s_fs_info = sbi;
        return &fsb->sb;

out:
        kfree(fsb);
        kfree(sbi);
        kfree(es);
        return NULL;
}

That VFS level struct super_block that is returned from this function is
never really initialized afaict? Therefore, sb->s_user_ns == NULL:

i_uid_write(sb, ...)
-> NULL = i_user_ns(sb)
   -> make_kuid(NULL)
      -> map_id_range_down(NULL)

Outside of this test this can never be the case. See alloc_super() in
fs/super.c. So to stop the bleeding this needs something like:

static struct super_block *mbt_ext4_alloc_super_block(void)
{
        struct ext4_super_block *es = kzalloc(sizeof(*es), GFP_KERNEL);
        struct ext4_sb_info *sbi = kzalloc(sizeof(*sbi), GFP_KERNEL);
        struct mbt_ext4_super_block *fsb = kzalloc(sizeof(*fsb), GFP_KERNEL);

        if (fsb == NULL || sbi == NULL || es == NULL)
                goto out;

        sbi->s_es = es;
        fsb->sb.s_fs_info = sbi;
+       fsb.sb.s_user_ns = &init_user_ns;
        return &fsb->sb;

out:
        kfree(fsb);
        kfree(sbi);
        kfree(es);
        return NULL;
}