linux-cve-announce - CVE-2022-50435: ext4: avoid crash when inline data creation follows DIO write

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>] [day] [month] [year] [list]

Message-ID: <2025100159-CVE-2022-50435-f6c4@gregkh>
Date: Wed,  1 Oct 2025 13:42:08 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2022-50435: ext4: avoid crash when inline data creation follows DIO write

From: Greg Kroah-Hartman <gregkh@...nel.org>

Description
===========

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

ext4: avoid crash when inline data creation follows DIO write

When inode is created and written to using direct IO, there is nothing
to clear the EXT4_STATE_MAY_INLINE_DATA flag. Thus when inode gets
truncated later to say 1 byte and written using normal write, we will
try to store the data as inline data. This confuses the code later
because the inode now has both normal block and inline data allocated
and the confusion manifests for example as:

kernel BUG at fs/ext4/inode.c:2721!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 359 Comm: repro Not tainted 5.19.0-rc8-00001-g31ba1e3b8305-dirty #15
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014
RIP: 0010:ext4_writepages+0x363d/0x3660
RSP: 0018:ffffc90000ccf260 EFLAGS: 00010293
RAX: ffffffff81e1abcd RBX: 0000008000000000 RCX: ffff88810842a180
RDX: 0000000000000000 RSI: 0000008000000000 RDI: 0000000000000000
RBP: ffffc90000ccf650 R08: ffffffff81e17d58 R09: ffffed10222c680b
R10: dfffe910222c680c R11: 1ffff110222c680a R12: ffff888111634128
R13: ffffc90000ccf880 R14: 0000008410000000 R15: 0000000000000001
FS:  00007f72635d2640(0000) GS:ffff88811b000000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000565243379180 CR3: 000000010aa74000 CR4: 0000000000150eb0
Call Trace:
 <TASK>
 do_writepages+0x397/0x640
 filemap_fdatawrite_wbc+0x151/0x1b0
 file_write_and_wait_range+0x1c9/0x2b0
 ext4_sync_file+0x19e/0xa00
 vfs_fsync_range+0x17b/0x190
 ext4_buffered_write_iter+0x488/0x530
 ext4_file_write_iter+0x449/0x1b90
 vfs_write+0xbcd/0xf40
 ksys_write+0x198/0x2c0
 __x64_sys_write+0x7b/0x90
 do_syscall_64+0x3d/0x90
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
 </TASK>

Fix the problem by clearing EXT4_STATE_MAY_INLINE_DATA when we are doing
direct IO write to a file.

The Linux kernel CVE team has assigned CVE-2022-50435 to this issue.


Affected and fixed versions
===========================

	Fixed in 4.9.331 with commit 3b31cc533665899965e351aae6cc3c3f3b9cc076
	Fixed in 4.14.296 with commit 43ed16910af200e2fcfe16986bee1a67fba94992
	Fixed in 4.19.262 with commit 59b108630a4987f71e1dc1dc50b8062e992b49c6
	Fixed in 5.4.220 with commit a22f52d883313bbfaf864669c14003f9456d4f8f
	Fixed in 5.10.150 with commit fb98cb61efff3b2a1964939465ccaaf906af1d4f
	Fixed in 5.15.75 with commit d8e4af8314df54d94cf2a541cf9c8626afe81d41
	Fixed in 5.19.17 with commit 89db2b50469bdbccb06ab072096d9d403124abac
	Fixed in 6.0.3 with commit 771f15782d95760cde352c8d4bfd6f2c70719568
	Fixed in 6.1 with commit 4bb26f2885ac6930984ee451b952c5a6042f2c0e

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2022-50435
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	fs/ext4/file.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/3b31cc533665899965e351aae6cc3c3f3b9cc076
	https://git.kernel.org/stable/c/43ed16910af200e2fcfe16986bee1a67fba94992
	https://git.kernel.org/stable/c/59b108630a4987f71e1dc1dc50b8062e992b49c6
	https://git.kernel.org/stable/c/a22f52d883313bbfaf864669c14003f9456d4f8f
	https://git.kernel.org/stable/c/fb98cb61efff3b2a1964939465ccaaf906af1d4f
	https://git.kernel.org/stable/c/d8e4af8314df54d94cf2a541cf9c8626afe81d41
	https://git.kernel.org/stable/c/89db2b50469bdbccb06ab072096d9d403124abac
	https://git.kernel.org/stable/c/771f15782d95760cde352c8d4bfd6f2c70719568
	https://git.kernel.org/stable/c/4bb26f2885ac6930984ee451b952c5a6042f2c0e