Kernel BUG in iomap_write_end() triggered by NTFS3 buffered write (Linux 7.0.1‑cachyos)

Issues & Assistance
1

Hello,

I encountered a kernel BUG related to buffered writes on an NTFS3 filesystem. The crash occurs inside the generic iomap buffered‑IO path, called from ntfs_file_write_iter(). This appears to be a kernel‑side logic error rather than a userspace issue.

The issue has happened multiple times, but it is not yet reliably reproducible. It seems to occur under similar conditions (writes from a 32‑bit process to an NTFS3 volume), but not on every attempt.

System Information

  • Distribution: CachyOS (Arch‑based)

  • Kernel: 7.0.1‑1‑cachyos (PREEMPT)

  • Hardware:

    • MSI MAG X570S Tomahawk Max WiFi (MS‑7D54)

    • BIOS 1.C0 (2025‑09‑03)

  • CPU: AMD Ryzen (8 cores visible in trace)

  • Filesystem involved: ntfs3

  • Taint flags: G O (NVIDIA out‑of‑tree module loaded)

  • Full system log:
    https://paste.cachyos.org/81db076.txt

Summary of the Issue

A kernel BUG is triggered during a buffered write to an NTFS3 filesystem.
The BUG originates in:

fs/iomap/buffered-io.c:1061
iomap_write_end+0x205/0x210

The write originates from a 32‑bit userspace process (Comm: CGenericAsyncFi), likely via int80 syscall emulation (Wine/Proton or similar).

This suggests a logic error in the interaction between NTFS3’s write_iter implementation and the generic iomap buffered write path.

Kernel Trace (excerpt)

kernel BUG at fs/iomap/buffered-io.c:1061!
Oops: invalid opcode: 0000 [#1] SMP NOPTI
CPU: 8 PID: 33291 Comm: CGenericAsyncFi Tainted: G O 7.0.1-1-cachyos
RIP: 0010:iomap_write_end+0x205/0x210
Call Trace:
iomap_file_buffered_write+0x283/0x490
ntfs_file_write_iter+0x2b3/0x300 [ntfs3]
vfs_write+0x2b6/0x3e0
__ia32_sys_write+0x84/0xf0
do_int80_emulation+0x136/0xa40

The full trace is included in the linked log file.

Reproduction Context

  • The issue has occurred multiple times, but not deterministically.

  • It always happened during writes to an NTFS3‑mounted volume.

  • The triggering process was a 32‑bit application performing write operations.

  • The crash occurs during buffered I/O, not direct I/O.

I can provide mount options or attempt further testing if needed.

Expected Behavior

Buffered writes to NTFS3 should complete normally without triggering a BUG in the iomap write‑end path.

Actual Behavior

The kernel hits a BUG() assertion in iomap_write_end(), causing an Oops and stack trace.
The system continues running, but the userspace process crashes.

Additional Notes

  • The kernel is tainted due to NVIDIA modules, but the crash occurs entirely within the filesystem and iomap code paths.

  • The BUG location suggests a logic error in iomap’s end‑write accounting or page state handling triggered by NTFS3.

  • I am able to test vanilla kernels or provide additional logs if required.

Please let me know if further debugging information, mount options, or additional testing would be helpful.

Thank you.

2

I can fairly reliably reproduce this while running Star Citizen (via LUG-Helper) and compiling the Vulkan shaders. The wiki clearly states that NTFS drives should be avoided (my mistake for missing that), but it appears this is why it fails to compile the shaders and hangs.

kernel BUG at fs/iomap/buffered-io.c:1061!
Oops: invalid opcode: 0000 [#16] SMP NOPTI
CPU: 12 UID: 1000 PID: 43487 Comm: StarCit:disk$2 Tainted: G D OE 7.0.2-2-cachyos #1 PREEMPT 9cc2a8119e87e130fcfac12053886be592987c58
RIP: 0010:iomap_write_end+0x205/0x210
Call Trace:
 <TASK>
 iomap_file_buffered_write+0x283/0x490
 ntfs_file_write_iter.llvm.4599753713976208697+0x341/0xba0 [ntfs3 fd626fe6e521ef8f6478435d3ed387c2e031b7f1]
 ? path_openat+0x5d3/0xea0
 __x64_sys_write+0x251/0x480
 do_syscall_64+0x6d/0xa90
 ? __x64_sys_openat+0x154/0x1c0
 ? do_syscall_64+0xa8/0xa90
 ? __x64_sys_openat+0x154/0x1c0
 ? do_syscall_64+0xa8/0xa90
 ? do_syscall_64+0xa8/0xa90
 ? do_syscall_64+0xa8/0xa90
 ? do_syscall_64+0xa8/0xa90
 ? do_syscall_64+0xa8/0xa90
 ? irqentry_exit+0x58/0x740
 entry_SYSCALL_64_after_hwframe+0x76/0x7e
3

And this is why I have never used the ntfs3 kernel driver and instead have kept using the ntfs-3g FUSE driver. For now, you can just switch over to ntfs-3g and things should work. If not, you may need to mount the partition in a Windows VM or baremetal and do a filesystem check before remounting in Linux.

5
6

I have the same buffered-io.c bug in ntfs3 (reportedhere)

And with ntfs-3g all directories on ntfs drives appear owned by root so I can’t use git as a normal user…

7

Use GNOME Disks (gnome-disk-utility) or whatever KDE’s equivalent is to “take ownership” of the partition. That should fix your issues.

I also use noatime, windows_names and hide_hid_files mounting options with the ntfs-3g FUSE driver, the last two are for better compatibility when sharing an NTFS partition between Windows and Linux. You can either use GNOME Disks to add mount options or directly edit the entry for the partition in /etc/fstab.

UUID=uuid_of_partition  /where/to/mount/partition  ntfs-3g  noatime,windows_names,hide_hid_files,...  0 0

Screenshot From 2026-05-17 13-45-34
Screenshot From 2026-05-17 13-45-34862×982 81.6 KB

8

The problem is I’m using ntfs-3g for all ntfs drives (ntfs_drivers=ntfs-3g) to avoid the buffered-io bug, and it automatically treats all directories as root owned. If I switch back to the default driver, the correct permissions & ownership are automatically restored.

9

Maybe aside but is there a reason to not use latest ntfs (“ntfsplus”) module?

10

I thought ntfs was not “stable”, I don’t want to risk corruptions