On Fri, Oct 09, 2026 at 10:02:47PM +0000, [email protected] wrote: > Does this change leave other readers of sbi->options vulnerable to a > use-after-free? > > While this patch protects ntfs_nls_to_utf16(), other VFS operations appear > to access sbi->options without holding rcu_read_lock() or s_umount. If a > thread is preempted immediately after loading the sbi->options pointer, and > a concurrent mount -o remount calls ntfs_fs_reconfigure() which replaces > sbi->options and schedules its destruction via call_rcu(), the grace period > can complete before the first thread resumes.
This is pre-existing. Before this patch ntfs_fs_reconfigure() swapped the options and put_fs_context() freed the old ones right when the remount returned. So all of these readers could already see freed options and now they at least have to stay preempted for a whole grace period. Making every sbi->options reader safe against a concurrent remount is a separate ntfs3 problem. This patch only cares about ntfs_nls_to_utf16() because that's what rcu pathwalk calls. > This problem wasn't introduced by this patch, but doesn't replacing > sbi->options with new_opts cause a silent loss of mount options during > remount? That's how ntfs3 remount has worked since it switched to the new mount api. Unrelated to this series.
