[Bug 2162663] [NEW] ntfs3: kernel BUG at fs/iomap/buffered-io.c:1061 in iomap_write_end on buffered writes — fixed upstream by 70d3855594cf, needs cherry-pick (7.0.y is EOL)

Public bug reported: [Impact] The in-kernel ntfs3 driver in the resolute kernel (7.0.0-28.28, and all 7.0 kernels) crashes with a kernel BUG on ordinary buffered writes to NTFS volumes: kernel BUG at fs/iomap/buffered-io.c:1061! Oops: invalid opcode: 0000 [#1] SMP NOPTI RIP: 0010:iomap_write_end+0x1e0/0x1f0 Call Trace: iomap_write_iter+0x171/0x340 iomap_file_buffered_write+0xa6/0x110 ntfs_file_write_iter+0x267/0x310 [ntfs3] vfs_write+0x25b/0x490 ksys_write+0x71/0xf0 __x64_sys_write+0x19/0x30 do_syscall_64+0x105/0x5a0 The writing task dies inside the write path while holding the folio lock and the inode i_rwsem, so it becomes an unkillable D-state task with SIGKILL pending forever; any process that later touches the same file/directory also hangs in D. The volume cannot be unmounted; only a reboot recovers, with attendant NTFS corruption risk on a filesystem frequently shared with a Windows dual-boot. Real-world triggers observed on this machine (multiple independent crashes across 2026-07-09 .. 2026-08-02): npm/node_modules installs, tar extraction, Steam game downloads, and Steam's fossilize shader-cache workers (comm fossilize_repla) — i.e. any many-small-file write workload. This makes an NTFS Steam library or dev tree on ntfs3 effectively unusable. Reports of the same signature exist from Arch/CachyOS users (e.g. https://github.com/CachyOS/linux-cachyos/issues/84). [Root cause / upstream status] Regression introduced by the ntfs3 iomap conversion in 7.0 (commit 099ef9ab9203 "fs/ntfs3: implement iomap-based file operations"): resident (small, MFT-inline) attributes are mapped as IOMAP_INLINE extents, but the inline buffer is allocated without page-alignment guarantees, so iomap_write_end()'s inline-data validity BUG_ON fires probabilistically on writes to small files. Upstream tracking: https://bugzilla.kernel.org/show_bug.cgi?id=221446 Upstream fix (mainline 7.2-rc1, via the ntfs3 for-7.2 pull): commit 70d3855594cf6e8791970714b65cac3202d6160e "ntfs3: Allocate iomap inline_data using alloc_page" (Fixes: 099ef9ab9203; Closes: bugzilla #221446; signed off by the ntfs3 maintainer) https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=70d3855594cf6e8791970714b65cac3202d6160e Crucially, this fix is NOT in any 7.0.y stable release — upstream 7.0.y ended at 7.0.14 without it (verified against the 7.0.1–7.0.14 changelogs), and it is also absent from 7.1.y through 7.1.5 (verified against ChangeLog-7.1.5). The regular stable-update SRU flow therefore can NEVER deliver this fix to the resolute kernel; it needs an explicit cherry-pick. [Fix] Please cherry-pick 70d3855594cf into the resolute linux package. It is a small, contained fs/ntfs3 change (allocation-alignment fix), carries Fixes:/Closes: tags, and applies to the 7.0 ntfs3 tree, which already contains the offending 099ef9ab9203. [Test Plan] On any NTFS volume mounted with the in-kernel ntfs3 driver, run a many-small-file write workload (e.g. `npm install` of a large dependency tree, or a Steam download/shader-cache build, or untar of a source tree). On affected kernels this reproduces the BUG within minutes to hours (probabilistic, alignment-dependent). With the fix applied the workload completes; no iomap_write_end BUG, no D-state leftovers. [Regression potential] Low: one-liner-scale allocation change confined to fs/ntfs3's inline-data path, authored and signed off by the subsystem maintainer, shipped in mainline since 7.2-rc1. [Workarounds until fixed] - Mount NTFS volumes with userspace ntfs-3g (FUSE) instead of ntfs3 (does not crash), or - Keep write-heavy workloads (node_modules, Steam libraries, shader caches) off ntfs3 volumes; do Steam downloads for shared libraries from the Windows side. ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2162663 Title: ntfs3: kernel BUG at fs/iomap/buffered-io.c:1061 in iomap_write_end on buffered writes — fixed upstream by 70d3855594cf, needs cherry-pick (7.0.y is EOL) Status in linux package in Ubuntu: New Bug description: [Impact] The in-kernel ntfs3 driver in the resolute kernel (7.0.0-28.28, and all 7.0 kernels) crashes with a kernel BUG on ordinary buffered writes to NTFS volumes: kernel BUG at fs/iomap/buffered-io.c:1061! Oops: invalid opcode: 0000 [#1] SMP NOPTI RIP: 0010:iomap_write_end+0x1e0/0x1f0 Call Trace: iomap_write_iter+0x171/0x340 iomap_file_buffered_write+0xa6/0x110 ntfs_file_write_iter+0x267/0x310 [ntfs3] vfs_write+0x25b/0x490 ksys_write+0x71/0xf0 __x64_sys_write+0x19/0x30 do_syscall_64+0x105/0x5a0 The writing task dies inside the write path while holding the folio lock and the inode i_rwsem, so it becomes an unkillable D-state task with SIGKILL pending forever; any process that later touches the same file/directory also hangs in D. The volume cannot be unmounted; only a reboot recovers, with attendant NTFS corruption risk on a filesystem frequently shared with a Windows dual-boot. Real-world triggers observed on this machine (multiple independent crashes across 2026-07-09 .. 2026-08-02): npm/node_modules installs, tar extraction, Steam game downloads, and Steam's fossilize shader-cache workers (comm fossilize_repla) — i.e. any many-small-file write workload. This makes an NTFS Steam library or dev tree on ntfs3 effectively unusable. Reports of the same signature exist from Arch/CachyOS users (e.g. https://github.com/CachyOS/linux-cachyos/issues/84). [Root cause / upstream status] Regression introduced by the ntfs3 iomap conversion in 7.0 (commit 099ef9ab9203 "fs/ntfs3: implement iomap-based file operations"): resident (small, MFT-inline) attributes are mapped as IOMAP_INLINE extents, but the inline buffer is allocated without page-alignment guarantees, so iomap_write_end()'s inline-data validity BUG_ON fires probabilistically on writes to small files. Upstream tracking: https://bugzilla.kernel.org/show_bug.cgi?id=221446 Upstream fix (mainline 7.2-rc1, via the ntfs3 for-7.2 pull): commit 70d3855594cf6e8791970714b65cac3202d6160e "ntfs3: Allocate iomap inline_data using alloc_page" (Fixes: 099ef9ab9203; Closes: bugzilla #221446; signed off by the ntfs3 maintainer) https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=70d3855594cf6e8791970714b65cac3202d6160e Crucially, this fix is NOT in any 7.0.y stable release — upstream 7.0.y ended at 7.0.14 without it (verified against the 7.0.1–7.0.14 changelogs), and it is also absent from 7.1.y through 7.1.5 (verified against ChangeLog-7.1.5). The regular stable-update SRU flow therefore can NEVER deliver this fix to the resolute kernel; it needs an explicit cherry-pick. [Fix] Please cherry-pick 70d3855594cf into the resolute linux package. It is a small, contained fs/ntfs3 change (allocation-alignment fix), carries Fixes:/Closes: tags, and applies to the 7.0 ntfs3 tree, which already contains the offending 099ef9ab9203. [Test Plan] On any NTFS volume mounted with the in-kernel ntfs3 driver, run a many-small-file write workload (e.g. `npm install` of a large dependency tree, or a Steam download/shader-cache build, or untar of a source tree). On affected kernels this reproduces the BUG within minutes to hours (probabilistic, alignment-dependent). With the fix applied the workload completes; no iomap_write_end BUG, no D-state leftovers. [Regression potential] Low: one-liner-scale allocation change confined to fs/ntfs3's inline-data path, authored and signed off by the subsystem maintainer, shipped in mainline since 7.2-rc1. [Workarounds until fixed] - Mount NTFS volumes with userspace ntfs-3g (FUSE) instead of ntfs3 (does not crash), or - Keep write-heavy workloads (node_modules, Steam libraries, shader caches) off ntfs3 volumes; do Steam downloads for shared libraries from the Windows side. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2162663/+subscriptions