PROBLEM: NULL pointer dereference in ext4_mb_load_buddy_gfp

PROBLEM: NULL pointer dereference in ext4_mb_load_buddy_gfp

[Bartos-Elekes Zsolt]

[-- Attachment #1: Type: text/plain, Size: 4889 bytes --]

Hi all,

The following oops happened after editing a few files (/etc/hostname, /etc/hosts), and running fstrim afterwards:


Nov  3 09:11:11  BUG: kernel NULL pointer dereference, address: 0000000000000000
Nov  3 09:11:11  #PF: supervisor read access in kernel mode
Nov  3 09:11:11  #PF: error_code(0x0000) - not-present page
Nov  3 09:11:11  PGD 0 P4D 0
Nov  3 09:11:11  Oops: 0000 [#1] PREEMPT SMP NOPTI
Nov  3 09:11:11  CPU: 0 PID: 1110 Comm: fstrim Not tainted 6.1.191 #1
Nov  3 09:11:11  Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
Nov  3 09:11:11  RIP: 0010:ext4_mb_load_buddy_gfp+0xb7/0x380
Nov  3 09:11:11  Code: 89 44 24 08 f7 3c 24 48 63 d8 89 54 24 0c ba 01 00 00 00 48 89 de e8 c8 8d e9 ff 49 89 c7 48 3d 
00 f0 ff ff 0f 87 28 01 00 00 <48> 8b 00 a8 04 0f 84 12 01 00 00 49 8b 07 a8 01 0f 85 07 01 00 00
Nov  3 09:11:11  RSP: 0018:ffffa90145d4fcd0 EFLAGS: 00010207
Nov  3 09:11:11  RAX: 0000000000000000 RBX: 000000000000005c RCX: 0000000000000001
Nov  3 09:11:11  RDX: 000000000000001c RSI: ffff891dc14f6b68 RDI: ffff891dc1de9500
Nov  3 09:11:11  RBP: ffff891dc1d0a000 R08: ffff891ddb3eaff8 R09: ffff891ddb3eafff
Nov  3 09:11:11  R10: 000000000000000d R11: 000000000000000e R12: ffffa90145d4fd48
Nov  3 09:11:11  R13: 0000000000000c40 R14: ffff891dc148bc78 R15: 0000000000000000
Nov  3 09:11:11  FS:  00007f2752636840(0000) GS:ffff891e3dc00000(0000) knlGS:0000000000000000
Nov  3 09:11:11  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Nov  3 09:11:11  CR2: 0000000000000000 CR3: 0000000005642004 CR4: 00000000007706f0
Nov  3 09:11:11  PKRU: 55555554
Nov  3 09:11:11  Call Trace:
Nov  3 09:11:11  <TASK>
Nov  3 09:11:11  ? ext4_trim_fs+0x219/0x3c0
Nov  3 09:11:11  ? __ext4_ioctl+0x948/0x19a0
Nov  3 09:11:11  ? __x64_sys_ioctl+0x44a/0xa00
Nov  3 09:11:11  ? syscall_exit_to_user_mode+0x22/0x40
Nov  3 09:11:11  ? do_syscall_64+0x65/0x90
Nov  3 09:11:11  ? clear_bhb_loop+0x50/0x9e
Nov  3 09:11:11  ? clear_bhb_loop+0x50/0x9e
Nov  3 09:11:11  ? clear_bhb_loop+0x50/0x9e
Nov  3 09:11:11  ? clear_bhb_loop+0x50/0x9e
Nov  3 09:11:11  ? entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Nov  3 09:11:11  </TASK>
Nov  3 09:11:11  Modules linked in: md5 cmac hmac nls_iso8859_2 cifs cifs_arc4 dns_resolver cifs_md4 
vmw_vsock_vmci_transport vsock bridge stp llc vmw_balloon crct10dif_pclmul crc32c_intel ghash_clmulni_intel sha512_ssse3 
sha512_generic sha256_ssse3 aesni_intel crypto_simd cryptd mousedev wdat_wdt sg vmxnet3 vmw_vmci
Nov  3 09:11:11  CR2: 0000000000000000
Nov  3 09:11:11  ---[ end trace 0000000000000000 ]---
Nov  3 09:11:11  RIP: 0010:ext4_mb_load_buddy_gfp+0xb7/0x380
Nov  3 09:11:11  Code: 89 44 24 08 f7 3c 24 48 63 d8 89 54 24 0c ba 01 00 00 00 48 89 de e8 c8 8d e9 ff 49 89 c7 48 3d 
00 f0 ff ff 0f 87 28 01 00 00 <48> 8b 00 a8 04 0f 84 12 01 00 00 49 8b 07 a8 01 0f 85 07 01 00 00
Nov  3 09:11:11  RSP: 0018:ffffa90145d4fcd0 EFLAGS: 00010207
Nov  3 09:11:11  RAX: 0000000000000000 RBX: 000000000000005c RCX: 0000000000000001
Nov  3 09:11:11  RDX: 000000000000001c RSI: ffff891dc14f6b68 RDI: ffff891dc1de9500
Nov  3 09:11:11  RBP: ffff891dc1d0a000 R08: ffff891ddb3eaff8 R09: ffff891ddb3eafff
Nov  3 09:11:11  R10: 000000000000000d R11: 000000000000000e R12: ffffa90145d4fd48
Nov  3 09:11:11  R13: 0000000000000c40 R14: ffff891dc148bc78 R15: 0000000000000000
Nov  3 09:11:11  FS:  00007f2752636840(0000) GS:ffff891e3dc00000(0000) knlGS:0000000000000000
Nov  3 09:11:11  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Nov  3 09:11:11  CR2: 0000000000000000 CR3: 0000000005642004 CR4: 00000000007706f0
Nov  3 09:11:11  PKRU: 55555554
Nov  3 09:11:11  note: fstrim[1110] exited with irqs disabled


The filesystem is on a thin-provisioned VMware virtual disk, and it was mounted with the "discard" option. After the 
oops, I had to reboot the machine, but after reboot and editing a few files, it happened again. I rebooted again, then I 
remounted the filesystem with the "nodiscard" option, and the problem went away.

A few hours later I could reproduce again the bug, but unfortunately I can't reproduce since then :-(

I run 6.1.x kernels, including 6.1.190 on several similar machines (with the same kernel config), but I never had such a 
problem.


Kernel version:

Linux version 6.1.191 (me@hostname) (gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 
SMP PREEMPT_DYNAMIC Tue Nov  3 04:00:00 CET 2026

Please find attached my kernel config and /proc/cpuinfo.

I was able to reproduce the bug a few times (but not now, unfortunately) with the following command:

while true; do tempfile="$(mktemp -p /tmp "test-XXXXXX")" && { echo "$tempfile"; echo "Ahoy" >> "$tempfile"; \
rm -f "$tempfile"; }; done

I let it run 10-20 seconds, hit ^C, and then run "fstrim -v /".

Please feel free to contact me if you need any further information.

-- 
Best regards,
Zsolt

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 26732 bytes --]

[-- Attachment #3: proc_cpuinfo.gz --]
[-- Type: application/gzip, Size: 799 bytes --]

Re: PROBLEM: NULL pointer dereference in ext4_mb_load_buddy_gfp

[Eric Biggers]

On Tue, Nov 03, 2026 at 03:26:08PM +0100, Bartos-Elekes Zsolt wrote:
> Linux version 6.1.191 (me@hostname) (gcc (Debian 12.2.0-14+deb12u1) 12.2.0,

Yes, the stable maintainers broke ext4 in 6.1.191.  The fix is
https://lore.kernel.org/linux-ext4/20261102-ext4-ntfs3-null-folio-v1-1-4fd91ee23a4a@elliotjb.com/

- Eric

Re: PROBLEM: NULL pointer dereference in ext4_mb_load_buddy_gfp

[Bartos-Elekes Zsolt]

Eric Biggers wrote:

> On Tue, Nov 03, 2026 at 03:26:08PM +0100, Bartos-Elekes Zsolt wrote:
>> Linux version 6.1.191 (me@hostname) (gcc (Debian 12.2.0-14+deb12u1) 12.2.0,
> 
> Yes, the stable maintainers broke ext4 in 6.1.191.  The fix is
> https://lore.kernel.org/linux-ext4/20261102-ext4-ntfs3-null-folio-v1-1-4fd91ee23a4a@elliotjb.com/

Thank you for the patch, I'll apply and test tomorrow.

-- 
Zsolt

Re: PROBLEM: NULL pointer dereference in ext4_mb_load_buddy_gfp

[Theodore Tso]

On Tue, Nov 03, 2026 at 08:47:21PM -0500, Bartos-Elekes Zsolt wrote:
> Eric Biggers wrote:
> 
> > On Tue, Nov 03, 2026 at 03:26:08PM +0100, Bartos-Elekes Zsolt wrote:
> > > Linux version 6.1.191 (me@hostname) (gcc (Debian 12.2.0-14+deb12u1) 12.2.0,
> > 
> > Yes, the stable maintainers broke ext4 in 6.1.191.  The fix is
> > https://lore.kernel.org/linux-ext4/20261102-ext4-ntfs3-null-folio-v1-1-4fd91ee23a4a@elliotjb.com/

Note that I *strongly* recommend that people use a kernel newer than
6.1 or 6.6.  A lot of security fixes don't get backported to the older
LTS kernels due to merge/cherry-pick conflicts, so your security team
might be prohibiting or strongly disuading you from using such ancient
LTS kernels.

Furthermore, the "it builds, ship it" approach towards backporting
fixes (including security fixes) is understandable, given the huge
influx of fixes to AI-discovered security vulnerability.
Unfortunately, it leads to frequent breakages to the older LTS
kernels, and I no longer have time to debug ext4 failures to 6.1 and
6.6 LTS kernels.

This is not to criticize those people who supply fixes to the 6.1 and
6.6 LTS kernels; in fact, I'm quite grateful for the people who do the
work to support those older LTS kernels.  And BTW, if someone is
willing to be the ext4 stable backports maintainer for the older LTS
kernels, and take on that responsibility in a more formal way. please
contact me off-line.

Cheers,

					- Ted

P.S.  It's not hard to monitor the 6.1-rc and 6.6-rc LTS kernels.
That part is automated, and I can supply an e-mail feed of the
automated runs of "gce-xfstests ltm -c ext4/all -g auto --repo
stable-rc.git --watch linux-6.1.y"

It's having a human being look at the huge number of test failures and
notice when there are new failures (regressions), and then when there
inevitably is a regression, doing the bisect to figure out which
backport caused the failure is the thing I don't have time to do.

Re: PROBLEM: NULL pointer dereference in ext4_mb_load_buddy_gfp

[Bartos-Elekes Zsolt]

Hi all,

> Yes, the stable maintainers broke ext4 in 6.1.191.  The fix is
> https://lore.kernel.org/linux-ext4/20261102-ext4-ntfs3-null-folio-v1-1-4fd91ee23a4a@elliotjb.com/

I applied this patch (and the fix for ntfs3 too), and everything seems to be OK.

Thank you for your help.

-- 
Zsolt