summaryrefslogtreecommitdiff
path: root/fs
AgeCommit message (Collapse)Author
2026-07-31affs: Move long delayed work on system_dfl_long_wqMarco Crivellari
Currently the code enqueue work items using {queue|mod}_delayed_work(), using system_long_wq. This workqueue should be used when long works are expected and it is a per-cpu workqueue. The function(s) end up calling __queue_delayed_work(), which set a global timer that could fire anywhere, enqueuing the work where the timer fired. Unbound works could benefit from scheduler task placement, to optimize performance and power consumption. Long work shouldn't stick to a single CPU. Recently, a new unbound workqueue specific for long running work has been added:     c116737e972e ("workqueue: Add system_dfl_long_wq for long unbound works") Since the workqueue work doesn't rely on per-cpu variables, there is no obvious reason that justify the use of a per-cpu workqueue. So change system_long_wq with system_dfl_long_wq so that the work may benefit from scheduler task placement. Cc: David Sterba <dsterba@suse.com> Cc: linux-fsdevel@vger.kernel.org Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Link: https://patch.msgid.link/20260706105443.173697-6-marco.crivellari@suse.com Acked-by: David Sterba <dsterba@suse.com> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-31hfs: Move long delayed work on system_dfl_long_wqMarco Crivellari
Currently the code enqueue work items using {queue|mod}_delayed_work(), using system_long_wq. This workqueue should be used when long works are expected and it is a per-cpu workqueue. The function(s) end up calling __queue_delayed_work(), which set a global timer that could fire anywhere, enqueuing the work where the timer fired. Unbound works could benefit from scheduler task placement, to optimize performance and power consumption. Long work shouldn't stick to a single CPU. Recently, a new unbound workqueue specific for long running work has been added:     c116737e972e ("workqueue: Add system_dfl_long_wq for long unbound works") Since the workqueue work doesn't rely on per-cpu variables, there is no obvious reason that justify the use of a per-cpu workqueue. So change system_long_wq with system_dfl_long_wq so that the work may benefit from scheduler task placement. Cc: Viacheslav Dubeyko <slava@dubeyko.com> Cc: John Paul Adrian Glaubitz Cc: Yangtao Li <frank.li@vivo.com> Cc: linux-fsdevel@vger.kernel.org Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Link: https://patch.msgid.link/20260706105443.173697-5-marco.crivellari@suse.com Reviewed-by: Viacheslav Dubeyko <slava@dubeyko.com> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-31hfsplus: Move long delayed work on system_dfl_long_wqMarco Crivellari
Currently the code enqueue work items using {queue|mod}_delayed_work(), using system_long_wq. This workqueue should be used when long works are expected and it is a per-cpu workqueue. The function(s) end up calling __queue_delayed_work(), which set a global timer that could fire anywhere, enqueuing the work where the timer fired. Unbound works could benefit from scheduler task placement, to optimize performance and power consumption. Long work shouldn't stick to a single CPU. Recently, a new unbound workqueue specific for long running work has been added:     c116737e972e ("workqueue: Add system_dfl_long_wq for long unbound works") Since the workqueue work doesn't rely on per-cpu variables, there is no obvious reason that justify the use of a per-cpu workqueue. So change system_long_wq with system_dfl_long_wq so that the work may benefit from scheduler task placement. Cc: Viacheslav Dubeyko <slava@dubeyko.com> Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Cc: Yangtao Li <frank.li@vivo.com> Cc: linux-fsdevel@vger.kernel.org Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Link: https://patch.msgid.link/20260706105443.173697-4-marco.crivellari@suse.com Reviewed-by: Viacheslav Dubeyko <slava@dubeyko.com> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-31fs/jffs2: Move long delayed work on system_dfl_long_wqMarco Crivellari
Currently the code enqueue work items using {queue|mod}_delayed_work(), using system_long_wq. This workqueue should be used when long works are expected and it is a per-cpu workqueue. The function(s) end up calling __queue_delayed_work(), which set a global timer that could fire anywhere, enqueuing the work where the timer fired. Unbound works could benefit from scheduler task placement, to optimize performance and power consumption. Long work shouldn't stick to a single CPU. Recently, a new unbound workqueue specific for long running work has been added:     c116737e972e ("workqueue: Add system_dfl_long_wq for long unbound works") Since the workqueue work doesn't rely on per-cpu variables, there is no obvious reason that justify the use of a per-cpu workqueue. So change system_long_wq with system_dfl_long_wq so that the work may benefit from scheduler task placement. Cc: David Woodhouse <dwmw2@infradead.org> Cc: Richard Weinberger <richard@nod.at> Cc: linux-mtd@lists.infradead.org Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Link: https://patch.msgid.link/20260706105443.173697-3-marco.crivellari@suse.com Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-31ufs: Move long delayed work on system_dfl_long_wqMarco Crivellari
Currently the code enqueue work items using {queue|mod}_delayed_work(), using system_long_wq. This workqueue should be used when long works are expected and it is a per-cpu workqueue. The function(s) end up calling __queue_delayed_work(), which set a global timer that could fire anywhere, enqueuing the work where the timer fired. Unbound works could benefit from scheduler task placement, to optimize performance and power consumption. Long work shouldn't stick to a single CPU. Recently, a new unbound workqueue specific for long running work has been added:     c116737e972e ("workqueue: Add system_dfl_long_wq for long unbound works") Since the workqueue work doesn't rely on per-cpu variables, there is no obvious reason that justify the use of a per-cpu workqueue. So change system_long_wq with system_dfl_long_wq so that the work may benefit from scheduler task placement. Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Kees Cook <kees@kernel.org> Cc: Eric Sandeen <sandeen@redhat.com> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Link: https://patch.msgid.link/20260706105443.173697-2-marco.crivellari@suse.com Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-31romfs: detect hard link cycles이상호
romfs_iget() follows on-disk hard link entries until it reaches a non-hard link inode: pos = be32_to_cpu(ri.spec) & ROMFH_MASK; The target position is image-controlled, and the loop does not detect cycles. A crafted romfs image can make the root inode a hard link. The hard link can point back to itself and leave mount(2) spinning in the kernel. Reject excessive hard link indirection with -ELOOP. Normal romfs images do not need long hard link chains. This bounds corrupted-image traversal. Propagate romfs_iget() errors from lookup because hard link traversal can now fail with -ELOOP. Signed-off-by: 이상호 <kudo3228@gmail.com> Link: https://patch.msgid.link/20260701220729.822112-1-kudo3228@gmail.com Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-30fs/proc: use softleaf_has_pfn() in pagemap PMD walkerUsama Arif
pagemap_pmd_range_thp() assumes that every non-present PMD is a migration entry and unconditionally calls softleaf_to_page(). This will crash on any non-present PMD type that does not encode a PFN, such as the upcoming PMD-level swap entries. Guard the page lookup with softleaf_has_pfn(), matching how pte_to_pagemap_entry() already handles non-present PTEs. Link: https://lore.kernel.org/20260706114320.1643046-4-usama.arif@linux.dev Signed-off-by: Usama Arif <usama.arif@linux.dev> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Zi Yan <ziy@nvidia.com> Cc: Alexandre Ghiti <alex@ghiti.fr> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Baoquan He <baoquan.he@linux.dev> Cc: Barry Song <baohua@kernel.org> Cc: Chris Li <chrisl@kernel.org> Cc: Dev Jain <dev.jain@arm.com> Cc: "Huang, Ying" <ying.huang@linux.alibaba.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Kairui Song <kasong@tencent.com> Cc: Kemeng Shi <shikemeng@huaweicloud.com> Cc: Kiryl Shutsemau <kas@kernel.org> Cc: Lance Yang <lance.yang@linux.dev> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Nhat Pham <nphamcs@gmail.com> Cc: Nico Pache <npache@redhat.com> Cc: Rik van Riel <riel@surriel.com> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Shakeel Butt <shakeel.butt@linux.dev> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30Merge tag 'v7.2-rc5-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6Linus Torvalds
Pull smb client fixes from Steve French: - fix SMB1 read and write potential buffer leaks - netfs error handling fix - fix check for last write time in truncate and setattr and cleanup use of smb_store_release() - fscache fix and cleanup - validate idmap key payload length - minor SMB1 error mapping cleanup - witness protocol memory allocation fix * tag 'v7.2-rc5-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6: cifs: add fscache_resize_cookie() to cifs_setsize() cifs: fix time_last_write stamp placement in setattr/truncate paths cifs: consolidate time_last_write stamp into _cifsFileInfo_put() smb: client: simplify cifs_fscache_get_super_cookie() smb: client: free partially allocated transform folio queue cifs: validate idmap key payload length smb: client: remove conditional return with no effect smb: client: fix buffer leaks in SMB1 read and write smb: client: use GFP_KERNEL for registry allocation
2026-07-30ksmbd: use memcmp() to compare ClientGUIDsNamjae Jeon
ClientGUID is a fixed-size binary value and can contain embedded NUL bytes. strncmp() stops comparing at the first NUL byte, so different ClientGUID values can incorrectly be treated as equal. Use memcmp() in SMB3 multichannel session binding and FSCTL_VALIDATE_NEGOTIATE_INFO to compare all SMB2_CLIENT_GUID_SIZE bytes. Fixes: f5a544e3bab7 ("ksmbd: add support for SMB3 multichannel") Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Reported-by: Samu <nomomentomori@gmail.com> Suggested-by: Samu <nomomentomori@gmail.com> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2026-07-30ksmbd: reject repeated SMB2 NEGOTIATE requestsNamjae Jeon
Unauthenticated client can send multiple successful SMB2 NEGOTIATE requests on one connection before SESSION_SETUP. While the connection is in KSMBD_SESS_NEED_SETUP, smb2_handle_negotiate() accepts another SMB3.1.1 NEGOTIATE and overwrites conn->preauth_info with a new allocation. Only the final allocation is freed when the connection is released, leaking one object for every additional successful request. A repeated SMB2 NEGOTIATE after a dialect has been selected is a protocol violation. MS-SMB2 section 3.3.5.4 requires the server to disconnect without replying in this case. Set the connection exiting when rejecting the request, in addition to suppressing the response. Reject SMB2 NEGOTIATE unless the connection is new or is waiting for the SMB2 NEGOTIATE that follows an SMB1 multi-protocol negotiate. Serialize both SMB1 and SMB2 negotiation paths under conn->srv_mutex, since they update connection-wide dialect and negotiation state. Move the locking contract to ksmbd_smb_negotiate_common(), where the state and dialect are selected, and add ksmbd_conn_new() for consistent state access. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Reported-by: Runa Takemoto <takemotoruna223@gmail.com> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2026-07-30ksmbd: fix use-after-free in __close_file_table_ids()Namjae Jeon
A ksmbd_file can remain alive after logical close while another session holds a temporary reference obtained through ksmbd_lookup_fd_inode(). ksmbd_close_fd() currently marks the file closed and drops the idr-owned reference, but leaves the pointer published in the closing session's idr until the final reference is dropped. If the foreign holder performs the final ksmbd_fd_put(), __put_fd_final() supplies the foreign session's file table to __ksmbd_close_fd(). The object is then freed without being removed from its owner's idr, and the owner session later dereferences the stale pointer during file-table teardown. Remove the volatile id from the owner's idr while ksmbd_close_fd() still holds that table's lock, and clear volatile_id before dropping the idr-owned reference. A later foreign final put then only performs physical destruction and cannot remove the object from the wrong table. Fixes: 8510a043d334 ("ksmbd: increment reference count of parent fp") Reported-by: Yunseong Kim <yunseong.kim@est.tech> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2026-07-30btrfs: trigger cow fixup via dirty_folio()Boris Burkov
The problem scenario: If we have a folio mmapped shared and then somebody does a dio read with that folio as the read destination, then it is possible that the dio will see a dirty destination page when it starts (and thus skip dirtying and just GUP pin it) but then while it is doing the read, btrfs finishes writing it back and by the endio, the folio is clean. In that case, the dio read must re-dirty the folio with aops->dirty_folio(): btrfs_check_read_bio() |- __iomap_dio_bio_end_io() from btrfs_bio_end_io() |- bio_check_pages_dirty() |- bio_dirty_fn() |- bio_release_pages(bio, true) |- __bio_release_pages(bio, mark_dirty == true) |- folio_lock() |- folio_mark_dirty() |- aops->dirty_folio() |- folio_unlock() A data block normally moves through writeback as follows: TASK folio_lock write clean -> dirty bit + delalloc folio_unlock WRITEBACK for-each-dirty-folio: folio_lock run_delalloc delalloc consumed -> dirty bit + OE submission dirty bit consumed -> writeback bit + OE folio_unlock ENDIO endio OE bytes accounted OE finish writeback -> clean; destroy OE Three critical invariants that this path maintains are: I1. Any dirty block is covered by delalloc xor an ordered extent I2. Any dirty block covered by an OE will be submitted into that OE I3. Any dirty block already submitted into an OE will not be submitted again into the same OE. These ensure that the block will be written exactly once. It is clear that not reserving delalloc for the re-dirty case violates I1. This situation, even without bs < folio_size, has long required btrfs to fixup such dirty pages during writeback with an asynchronous worker that is allowed to do this expensive work and writeback does not proceed for a folio while it is doing this work. Commit 247e743cbe6e ("Btrfs: Use async helpers to deal with pages that have been improperly dirtied") introduced the COW fixup to catch exactly this class at writeback, way back in 2008. Since then, there have been many advances to prevent most of the causes of such re-dirtying and we thought we could get away with removing the annoying cow-fixup in the hope of simplifying writeback for large folio support. Commit b2a9f217ad3f ("btrfs: remove the COW fixup mechanism") Commit 4927b141877c ("btrfs: remove folio ordered flag and subpage bitmap") Since it turns out this assumption was incorrect, as evidenced by the report and attendant reproducers, we must reintroduce the fixup concept. This is of course critically further complicated by bs < folio_size. In that case, rather than just a folio dirty bit, we have a bitmap for the dirty blocks in the folio. And the (also broken) invariant is: I4. folio dirty IFF at least one block bitmap dirty. The original report of a stall on a misinterpreted empty bitmap is exactly evidence of a violation of I4. It is exactly because of bs < folio_size we don't want to simply revert the removal patches. The original fixup was not properly bs < folio_size aware, which motivated removal in the first place. So we wish to build a bs < folio_size aware fixup. One other important detail from the old design, any normal write that happens after a re-dirty but before a fixup is racing with the cow fixup to do the delalloc reservation, therefore it must cancel the fixup state. If it arrives after the reservation exists, it will be a normal dirty overwrite. This critically informs the design in a pretty clear way. fixup requiring re-dirty has folio granularity, while cancellation has delalloc (block) granularity so while we only ever produce fixup in chunks of folios, we must be able to clear it in blocks. Therefore we must track the blocks needing fixup at block granularity. The obvious way to do this is with a new bitmap in btrfs_folio_state, but it is desirable to avoid that if possible. Unfortunately, I don't think it is possible and the reason is subtle and leans on a sort of extreme reproducer, but I think can be explained relatively succinctly. Consider a folio whose two halves will land in different ordered extents (can be accomplished with tricks using nodatasum) and a dio read is running with it as the shared mmap destination. 1. The front half: a. folio comes clean on a normal write b. dio read completes into the folio marking it fixup. c. a write comes for the previous folio for a range extending into this folio, this is a cancellation of the fixup which reserves space. d. writeback runs on the range *not* overlapping the folio. This half remains dirty but is now covered by an OE and is awaiting writeback running on its range to be submitted and finish the OE. 2. The back half: a. the folio is part of an OE that gets far enough along to clear writeback. b. dio read completes into the folio marking it fixup. After this, the folio's front half is dirty in the "normal" sense, it needs to be submitted to the OE waiting for it. It's a cancelled fixup. Meanwhile, the second half is a true fresh fixup. So at this point if we run writeback on this folio, we genuinely can't know what to do without block level information. If we submit it, we submit unreserved dirty from the back half. If we don't, we will never finish the OE waiting for it. So it's either a corruption or a deadlock. Thus, the full high level design picture: - btrfs_data_dirty_folio(): For out of band non-reserving dirties, mark still-clean blocks inside EOF dirty and set their fixup bits (the event carries no range, so every clean block is suspect). Already-dirty blocks are covered or pending and are left alone. - Writeback: skip fixup blocks and enqueue work for them - writepage_fixup(): for each fixup block do the fixup reservation in a worker, after which the blocks can be written back normally. - Typical reserving write paths cancel fixup state for the ranges they cover with btrfs_folio_cancel_fixup() Link: https://lore.kernel.org/linux-btrfs/20260721191152.101118-1-borntraeger@linux.ibm.com/ Assisted-by: LLM Reviewed-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Boris Burkov <boris@bur.io> Signed-off-by: David Sterba <dsterba@suse.com>
2026-07-30ext4: protect WRITE_ZEROES written extents with orphan listZhang Yi
In ext4_alloc_file_blocks(), the WRITE_ZEROES path converts unwritten extents to written in one transaction, while i_disksize is updated to cover them only in a later transaction. A crash in between leaves written extents beyond i_disksize on disk, which fsck will complain about. To fix this, add the inode to the orphan list in the same handle that does the conversion, and remove it once i_disksize has caught up. Also add a sanity check to ensure conversion does not extend beyond EOF. Since ext4_alloc_file_blocks() is called from the fallocate() path, partial allocation is safe. On partial conversion failure, advance i_disksize only up to the boundary of successfully converted blocks, so that orphan cleanup sees a consistent state. Document this behavior in the function comment. Reported-by: Jan Kara <jack@suse.cz> Closes: https://lore.kernel.org/linux-ext4/3f6ao5amv7glbgigndtegcucgo3n34ij3lau6l3da3hgdxgn3v@ev66wv3r5umt/ Fixes: f4265b8d32c4 ("ext4: add FALLOC_FL_WRITE_ZEROES support") Cc: stable@vger.kernel.org Signed-off-by: Zhang Yi <yi.zhang@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://patch.msgid.link/20260729085918.3336221-3-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2026-07-30ext4: export converted block count from ext4_convert_unwritten_extents()Zhang Yi
ext4_convert_unwritten_extents() currently returns only a success or a failure indication. A zero return means all requested blocks were converted, and a negative value means the conversion failed. However, some blocks may have already been converted when the function fails partway through, and callers have no way to learn how many were done. The WRITE_ZEROES caller in ext4_alloc_file_blocks() needs this information to decide whether to add the inode to the orphan list before updating i_disksize to cover the already-converted written extents, so that a crash before i_disksize catches up can be recovered via orphan truncation. Switch the function to pass out the number of converted blocks through the new output parameter @converted, which will be used by later patches. Signed-off-by: Zhang Yi <yi.zhang@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://patch.msgid.link/20260729085918.3336221-2-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2026-07-30ext4: fix incorrect function call when initializing s_resgidJiazi Liu
In __ext4_fill_super(), s_resgid is initialized by calling ext4_get_resuid() instead of ext4_get_resgid(), resulting in the reserved GID being set to the same value as the reserved UID rather than the value stored in the superblock. Fixes: 12c84dd4d308 ("ext4: add support for 32-bit default reserved uid and gid values") Cc: stable@vger.kernel.org Signed-off-by: Jiazi Liu <liujiazi@amazon.com> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Link: https://patch.msgid.link/20260727104103.28916-1-liujiazi@amazon.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2026-07-30ext4: validate EA inode i_nlink in ext4_xattr_inode_igetYun Zhou
Validate EA inode state in ext4_xattr_inode_iget() to reject corrupted EA inodes early, before they trigger WARN_ONCE in ext4_xattr_inode_update_ref(). When a corrupted ext4 image has an EA inode with inconsistent i_nlink and ref_count values (e.g. i_nlink=65535), the code currently allows it through and later hits WARN_ONCE when ref_count transitions cross the 0/1 boundary. This is better handled as an early sanity check that returns -EFSCORRUPTED, consistent with how ext4 treats other on-disk corruption. Since ext4_xattr_inode_iget() resolves references from active xattr entries, the target EA inode must be in active state (i_nlink=1, ref_count>0). Reject any inode that does not satisfy this. Reported-by: syzbot+76916a45d2294b551fd9@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=76916a45d2294b551fd9 Fixes: dec214d00e0d ("ext4: xattr inode deduplication") Signed-off-by: Yun Zhou <yun.zhou@windriver.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://patch.msgid.link/20260724100255.144768-1-yun.zhou@windriver.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2026-07-30udf: Fix data loss when converting inline inodes to out of lineJan Kara
When udf_expand_file_adinicb() converts file from inline format to out of line, we use filemap_fdatawrite() to writeout the data to the new blocks. However since 36580ed08776 ("udf: Do not allocate blocks on page writeback") the writeback actually doesn't allocate the new block and the folio dirty bit is just silently cleared. Thus unless the file is written to after the conversion (as it can easily happen in case of truncate up), the data is just lost. Fix the problem by explicitely allocating the block underlying the data before starting writeback. Fixes: 36580ed08776 ("udf: Do not allocate blocks on page writeback") CC: stable@vger.kernel.org Link: https://patch.msgid.link/20260730104232.4086759-4-jack@suse.cz Signed-off-by: Jan Kara <jack@suse.cz>
2026-07-30udf: Move udf_map_block() upJan Kara
Move udf_map_block() in the file to avoid forward declarations. Link: https://patch.msgid.link/20260730104232.4086759-3-jack@suse.cz Signed-off-by: Jan Kara <jack@suse.cz>
2026-07-30fs/namei.c: update kerneldoc of atomic_open()Jori Koolstra
The comments above atomic_open() contain several errors: - atomic_open() does not return 0 if successful - @path is not updated Fix those and be more explicit about when FMODE_OPENED and FMODE_CREATED are set. Change to a full kerneldoc. Signed-off-by: Jori Koolstra <jkoolstra@xs4all.nl> Link: https://patch.msgid.link/20260710164233.827744-4-jkoolstra@xs4all.nl Reviewed-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-30vfs: call audit_inode_child() in lookup_open() on failureJori Koolstra
audit_inode_child() is called in may_create_dentry() so that failed filesystem operations still register an audit entry. On success, the entry is overwritten when, for instance, fsnotify_create() is called. This is the calling convention in vfs_create() and vfs_mkdir(). In lookup_open(), however, when atomic_open() should have created a file but didn't, no call to audit_inode_child() is made. The same is true for the regular ->create() path. Fix the calling of audit_inode_child() in lookup_open() to match the vfs_create() path. For the ->atomic_open() filesystems this logic has been pushed into atomic_open(). This function is also reordered a bit to make the case distinction of the possible returns from ->atomic_open() more explicit (i.e. finish_open() or finish_no_open()). When retrying delegation breaking, audit_inode_child() could be called more than once, but this is OK because those entries are reused. Signed-off-by: Jori Koolstra <jkoolstra@xs4all.nl> Link: https://patch.msgid.link/20260710164233.827744-3-jkoolstra@xs4all.nl Acked-by: Paul Moore (audit) <paul@paul-moore.com> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-30vfs: move create error && negative dentry case in lookup_open() upJori Koolstra
O_CREAT is stripped when create_error is set in lookup_open(), so when lookup does not return an inode, the case if (!dentry->d_inode && (open_flag & O_CREAT)) is always skipped. We can get rid of this cognitive step by handling the error case first. Reviewed-by: NeilBrown <neil@brown.name> Signed-off-by: Jori Koolstra <jkoolstra@xs4all.nl> Link: https://patch.msgid.link/20260710164233.827744-2-jkoolstra@xs4all.nl Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-30fanotify: stop permission watchdog when timeout is zeroYichong Chen
The fanotify permission watchdog can be disabled by writing zero to fs/fanotify/watchdog_timeout. fanotify_perm_watchdog_group_add() already checks for a zero timeout before scheduling the watchdog. However, once the watchdog work has been scheduled, perm_group_watchdog() unconditionally schedules itself again with the current timeout. If the sysctl is changed to zero while the work is active, secs_to_jiffies(0) causes the work to be rescheduled immediately, resulting in a kworker busy loop. Read the timeout once in perm_group_watchdog_schedule() and do not schedule the work when it is zero. This lets a running watchdog stop after the next execution when the sysctl is set to zero. Fixes: b8cf8fda522d ("fanotify: add watchdog for permission events") Signed-off-by: Yichong Chen <chenyichong@uniontech.com> Link: https://patch.msgid.link/20260730070648.549458-1-chenyichong@uniontech.com Signed-off-by: Jan Kara <jack@suse.cz>
2026-07-30fs/ntfs3: Add basic support for alternative data streamsKonstantin Komarov
An ADS (alternative data stream) is a named $DATA (0x80) attribute. Until now ntfs3 ignored named data attributes entirely, so the only stream reachable from userspace was the unnamed one. Introduce a colon-delimited name syntax so streams can be reached through the regular VFS interfaces. ntfs_nls_to_utf16() now splits a lookup name at ':' and stores the stream part in cpu_str::ads_len (the previously unused padding byte). ntfs_iget5_flags() first instantiates the base inode, then allocates a second inode whose ->base points at it and whose ->file.ads holds the stream name. ntfs_test_inode() compares the stream name as well as the MFT reference, so base and streams get distinct inodes for the same record. Because the MFT record belongs to the base inode, the many helpers in frecord.c and attrlist.c that operate on the record redirect to ni->base, and ni_lock() and friends take the base inode's mutex. The attrib.c paths that used to hardcode an unnamed $DATA lookup now pass ni->file.ads.{name,len}. ni_write_inode() and ni_write_parents() are no-ops for stream inodes, and ntfs_setattr() drops ATTR_SIZE for them. Usage, for a file with streams 'ads1' and 'ads2': cat file:query_streams - list stream names, one per line cat file:ads1 - read a stream touch file:ads3 - create a stream on an existing file rm file:ads1 - remove a stream The pseudo-stream 'query_streams' is handled in ntfs_file_read_iter() via ni_query_ads(), which enumerates named $DATA attributes and returns their names separated by '\n'. The feature is controlled by the new 'ads' mount option, enabled by default; mount with 'ads=0' to restore the previous behaviour. Not implemented yet: - creating a file and a stream in a single call - renaming (moving) a stream Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
2026-07-30fs/ntfs3: Rename 'err' to 'ret' in read pathsKonstantin Komarov
ntfs_file_read_iter() and ntfs_file_splice_read() store both error codes and the number of bytes transferred in a variable named 'err', which is misleading on the success path. Rename it to 'ret'. While here, rename the 'in' parameter of ntfs_file_splice_read() to 'file' for consistency with the rest of the file, and add a local 'ni' instead of calling ntfs_i() inline. Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
2026-07-30fs/ntfs3: Fix memory leak in indx_find_sort()Konstantin Komarov
When popping a level from the index lookup stack, indx_find_sort() frees the struct indx_node but not the index buffer it owns. Every call that descends and then pops a level leaks that allocation. Free n->index before freeing the node itself. Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
2026-07-29ext2: Simplify error handling of IO error when adding xattrJan Kara
When we fail to write out inode when adding new xattr block, we backed out some changes (like quota modifications) but left others (like block allocation or inode xattr block modification). Just leave the inode intact in this case because we can hardly reach a consistent state and defer fixing to e2fsck. Also remove outdated comment and special data handling since sync_inode_metadata() does not write out any data. Link: https://patch.msgid.link/20260728154724.3934977-2-jack@suse.cz Signed-off-by: Jan Kara <jack@suse.cz>
2026-07-29fs/ntfs3: bound page_lcns[] index by the log recordKonstantin Komarov
The copy_lcns loop and the redo shorten loop index page_lcns[] at j + i, where i runs up to the log record's lcns_follow. That count is checked only against the record's own length, not the target entry, so check_dp_table() (which validates the entry's lcns_follow) does not cover it: the copy_lcns entry may even be freshly allocated after that check, and find_dp() bounds j but not i. A crafted record thus overflows page_lcns[] of an otherwise valid entry. Add dp_range_ok() and reject, before each loop, any record whose run does not fit the entry. These are the only two page_lcns[] accesses indexed by the record rather than the entry, so together with the entry validation every access is now bounded. Fixes: b46acd6a6a62 ("fs/ntfs3: Add NTFS journal") Cc: stable@vger.kernel.org Reported-by: Weiming Shi <bestswngs@gmail.com> Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei <xmei5@asu.edu> [almaz.alexandrovich@paragon-software.com: original patch contained changes to the problem already handled, applied partly] Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
2026-07-29fs/ntfs3: validate dirty page table on log replayXiang Mei
Each DIR_PAGE_ENTRY ends in a page_lcns[] array whose length is the on-disk lcns_follow field. check_rstbl() validates the table bookkeeping but never checks that this array fits in the entry, so a crafted lcns_follow lets the v0->v1 conversion memmove and later replay passes run off the entry. Add check_dp_table() to reject, right after check_rstbl(), any entry larger than its size claims via struct_size() (the same expression used to allocate these entries, so the check is overflow-safe by construction). All consumers can then trust lcns_follow as the real capacity. This covers every page_lcns[] access whose index is bounded by the entry itself (the conversion memmove, the HotFix store via find_dp(), and the self-bounded scan loops). Accesses whose index comes from the log record need a separate bound and are handled in a follow-up patch. Fixes: b46acd6a6a62 ("fs/ntfs3: Add NTFS journal") Cc: stable@vger.kernel.org Reported-by: Weiming Shi <bestswngs@gmail.com> Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei <xmei5@asu.edu> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
2026-07-29isofs: Drop support of directory entries straddling blocksJan Kara
Based on isofs standard (ECMA-119) directory entries are not allowed to straddle sector boundaries. Isofs images I have available seem to follow this. Now that we have code verifying validity of directory entries (and so we'd properly refuse such entries), let's just drop the code merging directory entries straddling sector boundaries. Acked-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Jan Kara <jack@suse.cz>
2026-07-29exfat: clean up new entry on add entry failureYichong Chen
exfat_add_entry() initializes a new directory entry set before writing it with exfat_put_dentry_set(). If the write fails, mkdir/create returns an error but a partially written entry may be left behind. For non-zero-size directories, the failure also happens after a cluster has been allocated for the new directory. Clean up the new entry best-effort, and free the newly allocated directory cluster only when the cleanup writeback succeeds. This avoids freeing a cluster that may still be referenced by an on-disk entry if the cleanup fails. Signed-off-by: Yichong Chen <chenyichong@uniontech.com> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
2026-07-28fs,fsverity: remove check for fsverity being enabled in setattr_prepare()Andrey Albershteyn
The check that fs-verity is available in the kernel is not necessary here. Filesystems could have fsverity files even without fs-verity enabled. In that case, truncate on fsverity file will succeed, what this check is trying to prevent. Fixes: e9734653c523 ("fs,fsverity: reject size changes on fsverity files in setattr_prepare") Cc: stable@vger.kernel.org Signed-off-by: Andrey Albershteyn <aalbersh@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260727094352.1734826-1-aalbersh@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-07-28fscrypt: use the mount idmap for the owner check in fscrypt_ioctl_set_policy()Zhan Xusheng
fscrypt_ioctl_set_policy() calls inode_owner_or_capable() with &nop_mnt_idmap before allowing an encryption policy to be set, instead of the idmap of the mount the ioctl was issued on. fscrypt is used by filesystems that support idmapped mounts (e.g. ext4, f2fs), so on such a mount this compares the caller's fsuid against the unmapped on-disk owner rather than the mapped owner: the actual owner can be wrongly denied with -EACCES and an unrelated caller wrongly allowed. Use file_mnt_idmap(filp) instead. Fixes: 14f3db5542e6 ("ext4: support idmapped mounts") Cc: stable@vger.kernel.org Signed-off-by: Zhan Xusheng <zhanxusheng@xiaomi.com> Link: https://patch.msgid.link/20260725080004.929328-1-zhanxusheng1024@gmail.com Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-07-28nilfs2: fix BUG in nilfs_copy_dirty_pages() on dirty state mismatchRyusuke Konishi
Syzbot reported a kernel BUG triggered within nilfs_copy_dirty_pages(), which copies dirty DAT file folios/pages to its shadow page cache. The BUG occurs when a retrieved dirty folio/page unexpectedly loses its 'dirty' status. This issue arises because, since the commit referenced below, the 'dirty' flag of a folio/page can be cleared asynchronously after the filesystem detects metadata corruption and transitions to read-only mode. Resolve the issue by returning an -EROFS error if the filesystem has transitioned to read-only mode. Also change the behavior to issue a kernel warning only once instead of triggering a kernel BUG when this unexpected 'dirty' state is detected while the filesystem is not in read-only mode. Reported-by: syzbot+8baf9a79a3ffc6271cb6@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=8baf9a79a3ffc6271cb6 Fixes: 8c26c4e2694a ("nilfs2: fix issue with flush kernel thread after remount in RO mode because of driver's internal error or metadata corruption") Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com> Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
2026-07-28nilfs2: prevent out-of-bounds read in super root block parsingDavid Lee
super-root inode metadata size is trusted before nilfs_read_inode_common(). Reject super-root inode sizes whose computed on-disk footprint exceeds the filesystem block size. This prevents malformed filesystem images from making nilfs_read_inode_common() read past the end of the super-root block. [ryusuke: clarify the commit title] Fixes: 8a9d2191e9f4 ("nilfs2: operations for the_nilfs core object") Signed-off-by: David Lee <david.lee@trailofbits.com> Assisted-by: Codex:gpt-5.5 Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com> Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
2026-07-28nilfs2: fix infinite loop in nilfs_clean_segments()Joshua Crofts
syzbot reported a hung task in nilfs_transaction_begin(). This occurs because the cleaner ioctl falls into an infinite loop if nilfs_segctor_construct() repeatedly returns -EROFS (e.g. the device is remounted as read-only after an I/O error). Currently in nilfs_clean_segments(), if err is non-zero, it logs the error and sleeps but doesn't abort when it encounters a terminal error like -EROFS. This causes the thread to loop forever. Fix this by breaking out of the loop if nilfs_segctor_construct() returns -EROFS. This matches the behaviour in nilfs_segctor_write_out(), which also handles -EROFS. Reported-by: syzbot+cae54346a70bbceeff2c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=cae54346a70bbceeff2c Fixes: 9ff05123e3bf ("nilfs2: segment constructor") Assisted-by: gemini:gemini-3.1-pro Signed-off-by: Joshua Crofts <joshua.crofts1@gmail.com> Acked-by: Ryusuke Konishi <konishi.ryusuke@gmail.com> Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
2026-07-28nilfs2: fix slab-out-of-bounds in nilfs_direct_propagate after truncationRyusuke Konishi
Shuangpeng Bai reported that KASAN detected a slab-out-of-bounds error in nilfs_direct_propagate() during testing. Analysis revealed that after truncating a file, a node block immediately below the B-tree root was not deleted. Instead, it remained in the B-tree node cache in a dirty state. The log writer subsequently detected this block and incorrectly invoked nilfs_direct_propagate() on it, which is designed to handle only data blocks in direct mapping. B-tree nodes in the cache are managed by virtual block numbers, and their logical keys typically exceed the range expected by direct mapping. Consequently, processing such a node as a direct mapping entry triggers a slab-out-of-bounds access. The root cause is that when a B-tree mapping collapses into a direct mapping during truncation, an intermediate node block pointed to by the root node is left behind as garbage instead of being explicitly deleted. This resolves the issue by adding a nilfs_btree_discard() operation to delete the remaining intermediate node block during the conversion. A 'deform' flag is added to the bop_delete interface to explicitly signal that the deletion is part of a mapping transformation. This allows the B-tree mapping implementation to perform the necessary cleanup and discarding of the residual node structure that would be otherwise be left orphaned after the transition. Reported-by: Shuangpeng Bai <shuangpeng.kernel@gmail.com> Closes: https://lore.kernel.org/r/08A3603A-ADB6-484C-9015-9AC1340E6FB8@gmail.com Fixes: 36a580eb489f ("nilfs2: direct block mapping") Cc: stable@vger.kernel.org Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com> Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
2026-07-28isofs: validate directory records consistentlyYichong Chen
isofs_export_get_parent() assumes that the first two directory records are valid "." and ".." entries. A malformed image can provide an invalid length for the first entry, causing the computed ".." offset to point outside the received block. Add a shared directory record validator and use it in NFS get_parent, readdir and lookup. This keeps the basic directory record length checks consistent across all directory users before they consume the name field or use one record length to find the next entry. Signed-off-by: Yichong Chen <chenyichong@uniontech.com> Link: https://patch.msgid.link/20260728074349.417508-1-chenyichong@uniontech.com Signed-off-by: Jan Kara <jack@suse.cz>
2026-07-28Merge tag 'for-7.2-rc5-tag' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull btrfs fixes from David Sterba: "Zoned mode: - fix assertion and handle case of finished zone and truncated extent - fix zone metadata write pointer on actual zone reset - fix deadlock caused metadata writeback and transaction commit - fix return value reuse leading to confusion about chunk reservations raid56 scrub: - fix tracking of sector checksums when there are not checksums found - fix inverted logic when submitting parity read bio mount/remount fixes: - fix leaking 'remount in progress' state which can break other operations to work (qgroup rescan, autodefrag, reclaim) - adjust using global block reserve after read-only mount when using rescue= option - handle missing raid stripe tree when mounted with 'ignorebadroots' Misc: - fix -Wmaybe-uninitialized warning in GET_CSUMS ioctl" * tag 'for-7.2-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: raid56: fix scrub read assembly submitting no reads btrfs: zoned: skip fully truncated ordered extents at zone finish btrfs: initialize 'args' to avoid compiler warning in btrfs_ioctl_get_csums() btrfs: zoned: fix missing chunk metadata reservation btrfs: raid56: fix an incorrect csum skip during scrub btrfs: report missing raid stripe tree root during lookup btrfs: skip global block reserve accounting for rescue mounts btrfs: zoned: reset meta_write_pointer on zone reset btrfs: zoned: fix deadlock between metadata writeback and transaction commit btrfs: fix leaking BTRFS_FS_STATE_REMOUNTING flag
2026-07-28binfmt_misc: don't leak the user namespace when the mount failsChristian Brauner
bm_get_tree() takes a reference to the user namespace and hands it to get_tree_keyed() as the sget key. sget_fc() moves that reference into sb->s_fs_info and clears fc->s_fs_info, so from that point on the superblock owns it and bm_free() doesn't see it anymore. The superblock drops it in ->put_super(). But generic_shutdown_super() only calls ->put_super() from inside the if (sb->s_root) branch, so nothing releases it when bm_fill_super() fails: - The kzalloc_obj() failure leaves s_root NULL and the whole branch is skipped. - A simple_fill_super() failure in the file loop leaves s_root set, but s_op still points at simple_super_operations, which has no ->put_super(). bm_fill_super() installs s_ops only once simple_fill_super() returned success, and installing it earlier wouldn't help either because simple_fill_super() overwrites s_op. Either way vfs_get_super() calls deactivate_locked_super() and the reference is gone for good. binfmt_misc mounts are available in a user namespace and both the inode and the dentry cache are SLAB_ACCOUNT, so an unprivileged caller under a tight memory cgroup can fail simple_fill_super() on demand and leak one user namespace per attempt. Drop the reference in ->kill_sb() instead, which runs unconditionally, the same way nfsd and rpc_pipefs release their keyed s_fs_info. That also stops ->put_super() from clearing s_fs_info while the superblock is still on @fs_supers. generic_shutdown_super() leaves it there on purpose so that sget_fc() keeps finding it until kill_sb() has run, but a NULL s_fs_info makes test_keyed_super() miss it, so a concurrent mount for the same user namespace skips the grab_super() wait and creates a second superblock for a namespace that is still being torn down. Link: https://patch.msgid.link/20260728-work-binfmt_misc-usernsleak-v1-1-dbd8d5e626e7@kernel.org Fixes: 21ca59b365c0 ("binfmt_misc: enable sandboxed mounts") Cc: stable@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-28binfmt_misc: reject a flag character as the field delimiterChristian Brauner
The registration string starts with a user chosen delimiter that separates the individual fields. So that the field parsers terminate even on a truncated string create_entry() pads the buffer with that same delimiter: memset(buf + count, del, 8); Most fields are scanned for the delimiter with strchr()/scanarg() and happily stop on the padding. The flags field is different: instead of scanning for the delimiter check_special_flags() consumes the flag characters 'P', 'O', 'C' and 'F' and stops at the first byte that is none of them, relying on the trailing delimiter to end the scan. If the delimiter is itself a flag character the padding no longer acts as a terminator. The scan swallows all eight padding bytes and keeps reading past the end of the allocation until it hits a byte that is not a flag character. For example registering PaPEPPxPPiP with 'P' as the delimiter (name "a", type extension, magic "x", interpreter "i", empty flags) leaves the flag scan running off the end of the buffer. The registration is rejected in the end because the parser does not stop exactly at buf + count, but only after the out of bounds read has already happened. With an unlucky allocation layout the scan can walk into an unmapped page; under KASAN it is reported as a slab out of bounds read. binfmt_misc mounts are available to unprivileged users in a user namespace so the read is reachable without privileges. Reject a delimiter that is one of the flag characters up front. Such a registration was always rejected anyway, only after the out of bounds read, so no valid registration string changes meaning. Link: https://patch.msgid.link/20260710-work-binfmt_misc-locking-v3-3-a162f7cb58d6@kernel.org Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-28binfmt_misc: use exe_file_deny_write_access() for the interpreter cloneChristian Brauner
For MISC_FMT_OPEN_FILE entries load_misc_binary() clones the registered interpreter file and denies write access to the clone via plain deny_write_access(). The clone is installed as bprm->interpreter and later released by the exec machinery through exe_file_allow_write_access() which skips the i_writecount increment for files with FMODE_FSNOTIFY_HSM set. The deny and allow side can therefore come to different conclusions when pre-content watches are in play: if a pre-content watch is added to the interpreter after registration every subsequent exec through that entry takes a write denial on the clone that is never paired with a write allowance, driving the interpreter inode's i_writecount further down with each exec and leaving the interpreter unwritable even after the entry and all its users are gone. Take the write denial via exe_file_deny_write_access() so both sides of the pairing base their decision on the same file mode, and propagate failure instead of silently ignoring it: an interpreter that is concurrently open for writing now fails the exec with ETXTBSY, exactly like an interpreter freshly opened via open_exec() would. Link: https://patch.msgid.link/20260710-work-binfmt_misc-locking-v3-2-a162f7cb58d6@kernel.org Fixes: 0357ef03c94e ("fs: don't block write during exec on pre-content watched files") Cc: stable@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-28binfmt_misc: restore write access when removing an entryChristian Brauner
Registering an entry with the MISC_FMT_OPEN_FILE flag opens the interpreter via open_exec() which denies write access to it for as long as the entry exists. Removing the entry closes the interpreter file via filp_close() but never restores write access, leaving the inode's i_writecount permanently negative. Opening the interpreter for writing keeps failing with ETXTBSY long after the entry is gone until the inode is evicted from the inode cache. Commit 90f601b497d7 ("binfmt_misc: restore write access before closing files opened by open_exec()") fixed the same imbalance in the error path of bm_register_write() but the actual removal path has been leaking the write denial since the introduction of the flag. Restore write access in put_binfmt_handler() before closing the interpreter file. Link: https://patch.msgid.link/20260710-work-binfmt_misc-locking-v3-1-a162f7cb58d6@kernel.org Fixes: 948b701a607f ("binfmt_misc: add persistent opened binary handler for containers") Cc: stable@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-28binfmt_misc: don't let an 'F' entry pin its own instanceChristian Brauner
An entry registered with 'F' opens its interpreter at registration time and holds that file until the entry is freed. Any entry nobody removes by hand only gets closed once the binfmt_misc superblock is shut down. If the interpreter lives on a mount that keeps that superblock alive the two pin each other: binfmt_misc sb -> inode -> entry -> interp_file -> vfsmount -> binfmt_misc sb TL;DR the file is never closed. Once the mount namespace is gone there is nothing left to unregister through either. There are two ways to trigger this bug: - Point the interpreter at the instance itself. Its files are regular files owned by the mounter and both bm_get_inode() and simple_fill_super() leave i_op at empty_iops. So notify_change() falls back to simple_setattr() and chmod +x works. We never set SB_I_NOEXEC and so open_exec() accepts it. - Use the instance as an overlayfs lower layer. The overlay superblock holds a clone_private_mount() of every layer until it is destroyed and that clone is in no namespace. So umount_tree() never reaches it. That's a DoS. And it isn't only the superblock that leaks. It pins the user namespace it was mounted in, so every iteration permanently eats one of the caller's user namespace charges. So let's just do the sane thing. SB_I_NOEXEC makes open_exec() fail on the instance's own files and s_stack_depth makes overlayfs reject the layer before it ever takes a clone. That also covers the ecryptfs and fuse passthrough variants. What 'F' promises is unchanged. The stable tag is narrower than the Fixes tags on purpose. Before sandboxed mounts this needed global root against the single instance everyone shares, and the change doesn't apply to those trees anyway. Note that SB_I_NODEV is implicitly raised for userns mounts but raise it explicitly here as well. Link: https://patch.msgid.link/20260728-work-binfmt_misc-selfpin-v1-1-74df5daeca5b@kernel.org Fixes: 948b701a607f ("binfmt_misc: add persistent opened binary handler for containers") Fixes: 21ca59b365c0 ("binfmt_misc: enable sandboxed mounts") Cc: stable@vger.kernel.org # v6.7+ Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-28netfs: Fix folio_queue ENOMEM in writeback by adding a mempoolDavid Howells
Fix the handling of folio_queue allocation failure in writeback by adding a mempool and passing in gfp_t flags to the rolling buffer functions that allocate memory, using the mempool if gfp != GFP_KERNEL. This is then extended upwards and the gfp to be used for a request is stored in the netfs_io_request struct and is then used for both requests and subrequests, eliminating the sleeping loops there. The failure caused: folio != NULL WARNING: fs/netfs/write_issue.c:603 at netfs_writepages+0x883/0xa10 fs/netfs/write_issue.c:603, CPU#3: syz.0.17/5919 Fixes: cd0277ed0c18 ("netfs: Use new folio_queue data type and iterator instead of xarray iter") Reported-by: syzbot+0da43efa72f88bd3a8af@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0da43efa72f88bd3a8af Signed-off-by: David Howells <dhowells@redhat.com> Link: https://patch.msgid.link/20260727130716.1099906-5-dhowells@redhat.com Tested-by: syzbot+0da43efa72f88bd3a8af@syzkaller.appspotmail.com cc: Paulo Alcantara <pc@manguebit.org> cc: Yun Zhou <yun.zhou@windriver.com> cc: Matthew Wilcox <willy@infradead.org> cc: Christoph Hellwig <hch@infradead.org> cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-28netfs: release readahead folios on iterator preparation failureYichong Chen
netfs_prepare_read_iterator() batches readahead folios in put_batch so that the folio references can be dropped after the I/O iterator has been prepared. If rolling_buffer_load_from_ra() fails after earlier folios have been batched, the function returns immediately and leaves those references held. Release the batch before returning the error. Fixes: 06fa229ceb36 ("netfs: Abstract out a rolling folio buffer implementation") Signed-off-by: Yichong Chen <chenyichong@uniontech.com> Signed-off-by: David Howells <dhowells@redhat.com> Link: https://patch.msgid.link/20260727130716.1099906-4-dhowells@redhat.com cc: Paulo Alcantara <pc@manguebit.org> cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-28netfs: handle single writeback rolling buffer allocation failureYichong Chen
netfs_write_folio_single() takes an extra folio reference before appending the folio to the rolling buffer. rolling_buffer_append() can fail if it cannot allocate another folio_queue. Check the return value and drop the extra folio reference before returning the error. Fixes: 49866ce7ea8d ("netfs: Add support for caching single monolithic objects such as AFS dirs") Signed-off-by: Yichong Chen <chenyichong@uniontech.com> Signed-off-by: David Howells <dhowells@redhat.com> Link: https://patch.msgid.link/20260727130716.1099906-3-dhowells@redhat.com cc: Paulo Alcantara <pc@manguebit.org> cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-28netfs: clear PG_private_2 on copy-to-cache append failureYichong Chen
netfs_pgpriv2_copy_to_cache() marks the folio with PG_private_2 before netfs_pgpriv2_copy_folio() appends it to the copy-to-cache rolling buffer. If the append fails, the folio is not queued for cache writeback, so the PG_private_2 state and its reference must be released immediately. Fixes: e2d46f2ec332 ("netfs: Change the read result collector to only use one work item") Signed-off-by: Yichong Chen <chenyichong@uniontech.com> Signed-off-by: David Howells <dhowells@redhat.com> Link: https://patch.msgid.link/20260727130716.1099906-2-dhowells@redhat.com cc: Paulo Alcantara <pc@manguebit.org> cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-28writeback: Export __inode_attach_wb()Christian Brauner
Commit c26339e1df33 ("ext4: Fix data integrity writeout issues in nojournal mode") made ext4_mark_iloc_dirty() attach the inode to a wb before marking it for metadata writeback in nojournal mode. This is the first modular caller of inode_attach_wb() - all users of __inode_attach_wb() so far were built-in - so with CONFIG_EXT4_FS=m and CONFIG_CGROUP_WRITEBACK=y the build now fails at the modpost stage: ERROR: modpost: "__inode_attach_wb" [fs/ext4/ext4.ko] undefined! Export the symbol. Use EXPORT_SYMBOL_GPL() to match the other cgroup writeback exports in this file. Fixes: c26339e1df33 ("ext4: Fix data integrity writeout issues in nojournal mode") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202607281811.F3c6kRvX-lkp@intel.com/ Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-28fs/ntfs3: reject restart table growth beyond U16_MAX entriesWeiming Shi
During $LogFile replay, log_replay() indexes the transaction table by the transact_id taken from the log record header. check_log_rec() only verifies that transact_id is non-zero and properly aligned, not its magnitude, so a crafted image can request an arbitrarily large index. alloc_rsttbl_from_idx() grows the table to cover that index via extend_rsttbl(), which passes the new entry count to init_rsttbl(): rt = init_rsttbl(esize, used + add); used + add is computed as u32 but init_rsttbl() takes a u16, and the count is stored in struct RESTART_TABLE as a __le16. When used + add exceeds U16_MAX it is truncated, init_rsttbl() allocates a table far smaller than the index requires, and alloc_rsttbl_from_idx() then dereferences and writes at the original, untruncated offset -- an out-of-bounds access past the allocation, reachable by mounting a crafted NTFS image. BUG: KASAN: use-after-free in alloc_rsttbl_from_idx (fs/ntfs3/fslog.c:950) Read of size 4 at addr ffff8880327ffff8 by task exploit alloc_rsttbl_from_idx (fs/ntfs3/fslog.c:950) log_replay (fs/ntfs3/fslog.c:4562) ntfs_loadlog_and_replay (fs/ntfs3/fsntfs.c:324) ntfs_fill_super (fs/ntfs3/super.c:1393) get_tree_bdev_flags vfs_get_tree path_mount __x64_sys_mount A restart table is limited to U16_MAX entries by its __le16 count, so a larger growth request is invalid input. Reject it in extend_rsttbl(); all callers already handle a NULL return. Fixes: b46acd6a6a62 ("fs/ntfs3: Add NTFS journal") Reported-by: Xiang Mei <xmei5@asu.edu> Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Weiming Shi <bestswngs@gmail.com> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
2026-07-28fs/ntfs3: fix info-leak on partial LZNT decompress in ni_read_frame()Samuel Page
ni_read_frame() decompresses an LZNT $DATA frame into the vmapped target pages and then trusts decompress_lznt()'s return value: unc_size = decompress_lznt(frame_ondisk, ondisk_size, frame_mem, frame_size); if ((ssize_t)unc_size < 0) err = unc_size; else if (!unc_size || unc_size > frame_size) err = -EINVAL; decompress_lznt() stops as soon as the compressed stream is exhausted (e.g. a zero chunk header) and returns the number of bytes it actually wrote, which may be far less than frame_size. The bytes between unc_size and frame_size are never written. The only memset() that follows zeroes the region beyond i_valid; when the frame lies entirely within the file's valid size that memset() does not run, so the gap retains whatever was in the just-vmapped pages. All pages are then marked uptodate and returned to userspace, disclosing uninitialized (recently-freed) kernel page memory. A crafted compressed file whose stream decompresses to only a few bytes leaks the remainder of every frame on a plain read(2), which is enough to recover kernel pointers and defeat KASLR. Zero the [unc_size, frame_size) tail immediately after a successful LZNT decompress so the remainder reads back as zero. Fixes: 4342306f0f0d ("fs/ntfs3: Add file operations and implementation") Cc: stable@vger.kernel.org Assisted-by: Bynario AI Signed-off-by: Samuel Page <sam@bynar.io> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>