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: <7c4f502e-0198-b941-39dc-90281564665b@huaweicloud.com>
Date: Thu, 29 Feb 2024 19:35:32 +0800
From: Kemeng Shi <shikemeng@...weicloud.com>
To: Christian Brauner <brauner@...nel.org>, 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>, 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 2/29/2024 6:09 PM, Christian Brauner wrote:
> 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;
> }
> 
Hi Christian,
Thanks for the information. I'm looking at this too and I also found
root cause is sb.s_user_ns is NULL. I'm considering to get a
super_block with VFS level api sget_fc to fix this to avoid similar
problem when new unit tests are added or new member is added to
super_block.
Would like to hear more from you. Thanks!