Re: [BUG] ext4: NULL/invalid pointer dereference in ext4_writepages() during generic/039

From: Ojaswin Mujoo

Date: Mon Aug 03 2026 - 16:02:51 EST

On Mon, Aug 03, 2026 at 12:22:35PM +0530, Ojaswin Mujoo wrote:
> On Mon, Aug 03, 2026 at 10:17:35AM +0530, Venkat Rao Bagalkote wrote:
> > Hi,
> >
> > I am seeing a reproducible kernel crash while running xfstests generic/039
> > on powerpc.
> >
> > The crash happens during ext4 journal recovery while mounting the
> > filesystem. The fault occurs inside ext4_writepages() and appears to
> > dereference a userspace-looking address.
> >
> > Test environment
> > ----------------
> > Kernel:
> > 7.2.0-rc5-next-20260731
> >
> > Architecture:
> > powerpc64le
> >
> > Platform:
> > IBM Power9 (pSeries)
> >
> > Machine:
> > IBM,8375-42A
> > FW950.80 (VL950_131)
> >
> > Config highlights:
> > PAGE_SIZE=64K
> > MMU=Hash
> > PREEMPTLAZY=y
> >
> > Workload
> > --------
> > xfstests generic/039
> >
> > Log excerpt:
> > run fstests generic/039 at 2026-08-03 00:22:44
> >
> > Crash
> > -----
> > [ 615.063689] Kernel attempted to read user page (fe73f0000) - exploit
> > attempt? (uid: 0)
> > [ 615.063714] BUG: Unable to handle kernel data access on read at
> > 0xfe73f0000
> > [ 615.063723] Faulting instruction address: 0xc008000015b0ed24
> > [ 615.063731] Oops: Kernel access of bad area, sig: 11 [#1]
> >
> > The faulting instruction is:
> >
> > ext4_writepages+0x12c/0x3a0
> >
> > Relevant call trace:
> >
> > ext4_writepages
> > do_writepages
> > __writeback_single_inode
> > writeback_single_inode
> > write_inode_now
> > iput_final
> > ext4_fc_replay
> > do_one_pass
> > jbd2_journal_recover
> > jbd2_journal_load
> > ext4_load_journal
> > ext4_load_and_init_journal
> > __ext4_fill_super
> > ext4_fill_super
> > get_tree_bdev_flags
> > ext4_get_tree
> > vfs_get_tree
> > vfs_cmd_create
> > __do_sys_fsconfig
> >
> > Full trace:
> >
> > [ 615.064100] NIP [c008000015b0ed24] ext4_writepages+0x12c/0x3a0 [ext4]
> > [ 615.064360] Call Trace:
> > [ 615.064383] do_writepages+0x190/0x330
> > [ 615.064395] __writeback_single_inode+0x9c/0x9e0
> > [ 615.064411] writeback_single_inode+0x18c/0x2b0
> > [ 615.064425] write_inode_now+0xc0/0x100
> > [ 615.064439] iput_final+0x10c/0x300
> > [ 615.064451] ext4_fc_replay+0x374/0xdd0 [ext4]
> > [ 615.064583] do_one_pass+0x9bc/0x1370 [jbd2]
> > [ 615.064627] jbd2_journal_recover[0x358/0x400 [jbd2]
> > [ [jbd2615.064670] jbd2_journal_load/0x110 [jbd2]
> > [ 615.064712] ext4_load_journal+0x2a0/0xb00 [ext4]
> > [ 615.064844] ext4_load_and_init_journal+0x6c/0x660 [ext4]
> > [ 615.064976] __ext4_fill_super+0x20b0/0x23a0 [ext4]
> >
> > Registers:
> >
> > DAR: 0x0000000fe73f0000
> > DSISR: 0x40000000
> >
> > The address being dereferenced (0xfe73f0000) looks like a userspace
> > address and triggers:
> >
> > "Kernel attempted to read user page - exploit attempt?"
> >
> >
> > Filesystem messages immediately prior to the crash:
> >
> > [ 614.718310] EXT4-fs (loop0): mounted filesystem
> > ee09878a-da42-4d97-81ed-1b9616af2fb4 r/w with ordered data mode. Quota mode:
> > journalled.
> > [ 614.984409] EXT4-fs (dm-0): mounted filesystem
> > b60397dc-c40f-4c75-bba9-bfc21f3a905a r/w with ordered data mode. Quota mode:
> > journalled.
> > [ 615.029979] EXT4-fs (dm-0): unmounting filesystem
> > b60397dc-c40f-4c75-bba9-bfc21f3a905a.
> >
> >
> > Meanwhile, I will attempt bisection.
> >
> > If you happen to fix this issue, please add below tag.
> >
> > Reported-by: Venkat Rao Bagalkote <venkat88@xxxxxxxxxxxxx>
> >
>
> Hey thanks for reporting this Venkat, I'll try to replicate this at my
> end.
>
> In the meantime, can you please share the complete Oops message and also
> your local.config.
>
> Thanks,
> ojaswin

(+cc Jan, Christian)

Okay so I'm able to replicate this in an x86 machine as well with 4kb
block size. The issue is replicable in vfs/vfs.all and is occurring
after Jan's change to nojournal mode writeout [1], with fast_commit.

The issue is as follows:

__ext4_fill_super
ext4_load_and_init_journal
...
jbd2_journal_recover
do_one_pass
fc_do_one_pass
...
ext4_fc_replay_unlink
__ext4_unlink
__ext4_mark_iloc_dirty
if (sbi->s_journal == NULL) // s_journal is not set yet
set_inode_metadata_writeback(inode); // sets I_METADATA_WRITEBACK
iput(inode)
iput_final(inode)
...
writeback_single_inode
__writeback_single_inode // since I_METADATA_WRITEBACK is set
...
ext4_writepages
ext4_writepages_down_read
percpu_down_read(sbi->s_writepages_rwsem)
<--- OOPS because this is initialized
later in ext4_percpu_param_init()

A simple fix seems to be to move ext4_percpu_param_init() call before
ext4_load_journal() so that we can safely call ext4_writepages(). The
below diff seems to be fixing the issue for me, does this look okay to
you Jan?

Also, venkat can you please help test this in your system:

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 2877a6cf6d09..6e05f191542c 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -5511,6 +5511,10 @@ static int __ext4_fill_super(struct fs_context *fc, struct super_block *sb)
goto failed_mount3a;
}

+ err = ext4_percpu_param_init(sbi);
+ if (err)
+ goto failed_mount3a;
+
err = -EINVAL;
/*
* The first inode we look at is the journal inode. Don't try
@@ -5659,10 +5663,6 @@ static int __ext4_fill_super(struct fs_context *fc, struct super_block *sb)
clear_opt2(sb, MB_OPTIMIZE_SCAN);
}

- err = ext4_percpu_param_init(sbi);
- if (err)
- goto failed_mount5;
-
err = ext4_mb_init(sb);
if (err) {
ext4_msg(sb, KERN_ERR, "failed to initialize mballoc (%d)",
@@ -5764,7 +5764,6 @@ failed_mount8: __maybe_unused
ext4_mb_release(sb);
ext4_flex_groups_free(sbi);
failed_mount5:
- ext4_percpu_param_destroy(sbi);
ext4_ext_release(sb);
ext4_release_system_zone(sb);
failed_mount4a:
@@ -5785,6 +5784,7 @@ failed_mount8: __maybe_unused
ext4_journal_destroy(sbi, sbi->s_journal);
}
failed_mount3a:
+ ext4_percpu_param_destroy(sbi);
ext4_es_unregister_shrinker(sbi);
failed_mount3:
/* flush s_sb_upd_work before sbi destroy */

[1] https://lore.kernel.org/linux-ext4/20260727104923.3828017-37-jack@xxxxxxx/
> >
> >
> > Thanks,
> > Venkat.
> >