CVE-2023-53100

In the Linux kernel, the following vulnerability has been resolved:

ext4: fix WARNING in ext4updateinline_data

Syzbot found the following issue: EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 without journal. Quota mode: none. fscrypt: AES-256-CTS-CBC using implementation "cts-cbc-aes-aesni" fscrypt: AES-256-XTS using implementation "xts-aes-aesni" ------------[ cut here ]------------ WARNING: CPU: 0 PID: 5071 at mm/pagealloc.c:5525 allocpages+0x30a/0x560 mm/pagealloc.c:5525 Modules linked in: CPU: 1 PID: 5071 Comm: syz-executor263 Not tainted 6.2.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 RIP: 0010:allocpages+0x30a/0x560 mm/pagealloc.c:5525 RSP: 0018:ffffc90003c2f1c0 EFLAGS: 00010246 RAX: ffffc90003c2f220 RBX: 0000000000000014 RCX: 0000000000000000 RDX: 0000000000000028 RSI: 0000000000000000 RDI: ffffc90003c2f248 RBP: ffffc90003c2f2d8 R08: dffffc0000000000 R09: ffffc90003c2f220 R10: fffff52000785e49 R11: 1ffff92000785e44 R12: 0000000000040d40 R13: 1ffff92000785e40 R14: dffffc0000000000 R15: 1ffff92000785e3c FS: 0000555556c0d300(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f95d5e04138 CR3: 00000000793aa000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> _allocpagesnode include/linux/gfp.h:237 [inline] allocpagesnode include/linux/gfp.h:260 [inline] _kmalloclargenode+0x95/0x1e0 mm/slabcommon.c:1113 _dokmallocnode mm/slabcommon.c:956 [inline] _kmalloc+0xfe/0x190 mm/slabcommon.c:981 kmalloc include/linux/slab.h:584 [inline] kzalloc include/linux/slab.h:720 [inline] ext4updateinlinedata+0x236/0x6b0 fs/ext4/inline.c:346 ext4updateinlinedir fs/ext4/inline.c:1115 [inline] ext4tryaddinlineentry+0x328/0x990 fs/ext4/inline.c:1307 ext4addentry+0x5a4/0xeb0 fs/ext4/namei.c:2385 ext4addnondir+0x96/0x260 fs/ext4/namei.c:2772 ext4create+0x36c/0x560 fs/ext4/namei.c:2817 lookupopen fs/namei.c:3413 [inline] openlastlookups fs/namei.c:3481 [inline] pathopenat+0x12ac/0x2dd0 fs/namei.c:3711 dofilpopen+0x264/0x4f0 fs/namei.c:3741 dosysopenat2+0x124/0x4e0 fs/open.c:1310 dosysopen fs/open.c:1326 [inline] _dosysopenat fs/open.c:1342 [inline] _sesysopenat fs/open.c:1337 [inline] _x64sysopenat+0x243/0x290 fs/open.c:1337 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x3d/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd

Above issue happens as follows: ext4iget ext4findinlinedatanolock ->iinlineoff=164 iinlinesize=60 ext4tryaddinlineentry _ext4markinodedirty ext4expandextraisizeea ->iextraisize=32 swantextraisize=44 ext4xattrshiftentries ->after shift iinlineoff is incorrect, actually is change to 176 ext4tryaddinlineentry ext4updateinlinedir getmaxinlinexattrvaluesize if (EXT4I(inode)->iinlineoff) entry = (struct ext4xattrentry *)((void *)rawinode + EXT4I(inode)->iinlineoff); free += EXT4XATTRSIZE(le32tocpu(entry->evaluesize)); ->As entry is incorrect, then 'free' may be negative ext4updateinlinedata value = kzalloc(len, GFPNOFS); -> len is unsigned int, maybe very large, then trigger warning when 'kzalloc()'

To resolve the above issue we need to update 'iinlineoff' after 'ext4xattrshiftentries()'. We do not need to set EXT4STATEMAYINLINEDATA flag here, since ext4markinodedirty() already sets this flag if needed. Setting EXT4STATEMAYINLINEDATA when it is needed may trigger a BUGON in ext4writepages().