linux-kernel - Re: [PATCH] mm/slub: fix to return errno if kmalloc() fails

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]

Date:   Thu, 8 Sep 2022 23:25:08 +0200
From:   "Vlastimil Babka (SUSE)" <vbabka@...nel.org>
To:     Muchun Song <muchun.song@...ux.dev>, Chao Yu <chao@...nel.org>
Cc:     Linux MM <linux-mm@...ck.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-kernel@...r.kernel.org, jaegeuk@...nel.org,
        Chao Yu <chao.yu@...o.com>, stable@...nel.org,
        syzbot+81684812ea68216e08c5@...kaller.appspotmail.com,
        David Rientjes <rientjes@...gle.com>,
        Hyeonggon Yoo <42.hyeyoo@...il.com>,
        Christoph Lameter <cl@...ux.com>
Subject: Re: [PATCH] mm/slub: fix to return errno if kmalloc() fails

On 8/31/22 05:09, Muchun Song wrote:
> 
> 
>> On Aug 30, 2022, at 22:10, Chao Yu <chao@...nel.org> wrote:

Please use scripts/get_maintainer.pl next time, I could have missed this.

>> From: Chao Yu <chao.yu@...o.com>
>> 
>> In create_unique_id(), kmalloc(, GFP_KERNEL) can fail due to
>> out-of-memory, if it fails, return errno correctly rather than
>> triggering panic via BUG_ON();
> 
> I tend to agree with you. A mount operation shouldn’t panic the
> kernel.

Hmm kmalloc(64) shouldn't normally due that due to the the underlying page
allocation falling into the "too small to fail" category, wonder if
syzkaller was doing anything special here?

But yeah we should get rid of all BUG_ONs eventually, just not sure if
stable@ is needed here.

>> 
>> kernel BUG at mm/slub.c:5893!
>> Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
>> 
>> Call trace:
>> sysfs_slab_add+0x258/0x260 mm/slub.c:5973
>> __kmem_cache_create+0x60/0x118 mm/slub.c:4899
>> create_cache mm/slab_common.c:229 [inline]
>> kmem_cache_create_usercopy+0x19c/0x31c mm/slab_common.c:335
>> kmem_cache_create+0x1c/0x28 mm/slab_common.c:390
>> f2fs_kmem_cache_create fs/f2fs/f2fs.h:2766 [inline]
>> f2fs_init_xattr_caches+0x78/0xb4 fs/f2fs/xattr.c:808
>> f2fs_fill_super+0x1050/0x1e0c fs/f2fs/super.c:4149
>> mount_bdev+0x1b8/0x210 fs/super.c:1400
>> f2fs_mount+0x44/0x58 fs/f2fs/super.c:4512
>> legacy_get_tree+0x30/0x74 fs/fs_context.c:610
>> vfs_get_tree+0x40/0x140 fs/super.c:1530
>> do_new_mount+0x1dc/0x4e4 fs/namespace.c:3040
>> path_mount+0x358/0x914 fs/namespace.c:3370
>> do_mount fs/namespace.c:3383 [inline]
>> __do_sys_mount fs/namespace.c:3591 [inline]
>> __se_sys_mount fs/namespace.c:3568 [inline]
>> __arm64_sys_mount+0x2f8/0x408 fs/namespace.c:3568
>> 
>> Cc: <stable@...nel.org>
>> Reported-by: syzbot+81684812ea68216e08c5@...kaller.appspotmail.com
>> Signed-off-by: Chao Yu <chao.yu@...o.com>
> 
> Reviewed-by: Muchun Song <songmuchun@...edance.com>
> 
> Thanks.
> 
>