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

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 <[email protected]>
> > 
> 
> 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;