Move the call to fuse_send_readpages from the iomap ->submit_read method
to the fuse readahead implementation.
fuse_read_folio() does not need to call fuse_send_readpages() because it
always does reads synchronously (the iomap->submit_read method for this
was a no-op since data->ia is always NULL for fuse_read_folio()).
This prepares for an iomap fix that will call ->submit_read after each
iomap.
Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://patch.msgid.link/20260629121750.3392300-3-hch@lst.de
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Add a iomap_bio_submit_read_endio helper factored out of
iomap_bio_submit_read to that all ->submit_read implementations for
iomap_read_ops that use iomap_bio_read_folio_range can shared the
logic.
Right now that logic is mostly trivial, but already has a bug for XFS
because the XFS version is too trivial: file system integrity validation
needs a workqueue context and thus can't happen from the default iomap
bi_end_io I/O handler. Unfortunately the iomap refactoring just before
fs integrity landed moved code around here and the call go misplaced,
meaning it never got called. The PI information still is verified by
the block layer, but the offloading is less efficient (and the future
userspace interface can't get at it).
Fixes: 0b10a37052 ("iomap: support T10 protection information")
Cc: stable@vger.kernel.org # v7.1
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://patch.msgid.link/20260629121750.3392300-2-hch@lst.de
Acked-by: Namjae Jeon <linkinjeon@kernel.org>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Joanne Koong <joannelkoong@gmail.com>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
The recent fhandle RCU fix moved the mount namespace capability check
into capable_wrt_mount(), so a non-NULL mnt_namespace survives the
ns_capable() dereference. The helper still assumes the later
READ_ONCE(mount->mnt_ns) must be non-NULL because may_decode_fh()
checked is_mounted() first.
That assumption is not stable. A detached mount from
open_tree(..., OPEN_TREE_CLONE) can be dissolved on fput while
open_by_handle_at() is between those checks, and umount_tree() can
clear mount->mnt_ns. If the helper observes NULL, it dereferences
mnt_ns->user_ns and panics.
Return false when the RCU read observes a detached mount. This keeps
the relaxed permission path conservative: a mount no longer attached
to a namespace cannot authorize open_by_handle_at() access.
Fixes: 620c266f39 ("fhandle: relax open_by_handle_at() permission checks")
Cc: stable@vger.kernel.org
Signed-off-by: David Lee <david.lee@trailofbits.com>
Assisted-by: LLM
Link: https://patch.msgid.link/20260701114438.24431-1-david.lee@trailofbits.com
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
David Howells <dhowells@redhat.com> says:
Here are some miscellaneous fixes for netfslib. I separated them from my
netfs-next branch. Various Sashiko review comments[1][2][3] are addressed:
(1) Fix the decision whether to disallow write-streaming due to fscache
use.
(2) Fix netfs_create_write_req() to better handle async cache object
creation.
(3) Fix a double fput in cachefiles_create_tmpfile().
(4) Fix alteration of S_KERNEL_FILE inode flag without holding inode lock.
(5) Fix a potential mathematical underflow in
iov_iter_extract_xarray_pages() and make it return 0 and free the
array if no pages could be extracted.
(6) Fix a missing alloc failure check in iov_iter_extract_bvec_pages().
(7) Fix iov_iter_extract_user_pages() so that it doesn't leak the pages
array if it returns an error or 0 (inasmuch as the leak is really in
the callers).
(8) Remove an unused variable in kunit_iov_iter.c.
(9) Fix extract_xarray_to_sg() to calculate folio offset correctly.
(10) Fix a kdoc comment.
(11) Replace the netfs_inode::wb_lock mutex with a bit lock so that the
lock can be passed to the collector so that multiple asynchronous
writebacks won't interfere with each other.
(12) Fix writeback error handling to go through writeback_iter() so that it
can clean up its state.
(13) Fix ENOMEM handling in writeback to clean up the current folio if we
can't allocate a rolling buffer segment.
(14) Fix unbuffered/DIO write retry for filesystems that don't have a
->prepare_write() method.
[1] https://sashiko.dev/#/patchset/20260608145432.681865-1-dhowells%40redhat.com
[2] https://sashiko.dev/#/patchset/20260616100821.2062304-1-dhowells%40redhat.com
[3] https://sashiko.dev/#/patchset/20260619140646.2633762-1-dhowells%40redhat.com
[4] https://sashiko.dev/#/patchset/20260624115737.2964520-1-dhowells%40redhat.com
* patches from https://patch.msgid.link/20260625140640.3116900-1-dhowells@redhat.com:
netfs: Fix DIO write retry for filesystems without a ->prepare_write()
netfs: Fix folio state after ENOMEM whilst under writeback iteration
netfs: Fix writeback error handling
netfs: Fix writethrough to use collection offload
netfs: Replace wb_lock with a bit lock for asynchronicity
netfs: Fix kdoc warning
scatterlist: Fix offset in folio calc in extract_xarray_to_sg()
iov_iter: Remove unused variable in kunit_iov_iter.c
iov_iter: Fix a memory leak in iov_iter_extract_user_pages()
iov_iter: Fix missing alloc fail check in iov_iter_extract_bvec_pages()
iov_iter: Fix potential underflow in iov_iter_extract_xarray_pages()
cachefiles: Fix file burial to take lock when unsetting S_KERNEL_FILE
cachefiles: Fix double fput
netfs: Fix netfs_create_write_req() to handle async cache object creation
netfs: Fix decision whether to disallow write-streaming due to fscache use
Link: https://patch.msgid.link/20260625140640.3116900-1-dhowells@redhat.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Fix netfs_unbuffered_write() so that it doesn't re-issue a write twice when
the filesystem doesn't have a ->prepare_write(). The resetting of the
iterator and the call to netfs_reissue_write() should just be removed as
almost everything it does is done again when the loop it's in goes back to
the top.
It does, however, still need the IN_PROGRESS flag setting, so that (and the
stat inc) are moved out of the if-statement.
Further, the MADE_PROGRESS flags should be cleared and wreq->transferred
should be updated, so fix those too.
Reported-by: syzbot+3c74b1f0c372e98efc32@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=3c74b1f0c372e98efc32
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://patch.msgid.link/20260625140640.3116900-16-dhowells@redhat.com
cc: Paulo Alcantara <pc@manguebit.org>
cc: hongao <hongao@uniontech.com>
cc: ChenXiaoSong <chenxiaosong@chenxiaosong.com>
cc: netfs@lists.linux.dev
cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
The netfs_inode::wb_lock mutex is used to prevent multiple simultaneous
writebacks from fighting each other (a writeback thread will write multiple
discontiguous regions within the same request). The mutex, however, only
serialises the issuing of subrequests; it doesn't serialise the collection
of results, and, in particular, the updating of file size information and
fscache populatedness data.
Unfortunately, the mutex cannot be held around the entire process as it has
to be unlocked in the same thread in which it is locked - and we don't want
to hold up the allocator whilst we complete the writeback.
Fix this by replacing the mutex with a bit flag and a list of lock waiters
so that the lock can be dropped in the collector thread after collection is
complete.
Link: https://sashiko.dev/#/patchset/20260608145432.681865-1-dhowells%40redhat.com
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://patch.msgid.link/20260625140640.3116900-12-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>
Remove the no longer used variable 'b' from iov_kunit_copy_to_bvec(). The
variable is initialised and incremented, but nothing now makes use of the
value.
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://patch.msgid.link/20260625140640.3116900-9-dhowells@redhat.com
Reviewed-by: Christoph Hellwig <hch@lst.de>
cc: Ming Lei <ming.lei@redhat.com>
cc: Paulo Alcantara <pc@manguebit.org>
cc: Matthew Wilcox <willy@infradead.org>
cc: Christoph Hellwig <hch@infradead.org>
cc: Jens Axboe <axboe@kernel.dk>
cc: netfs@lists.linux.dev
cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
There's a potential memory leak in callers of iov_iter_extract_user_pages()
whereby if a pages array is allocated in function, it isn't freed before
returning of an error or 0.
Now, it's not a leak per se in iov_iter_extract_user_pages() as, if an
array is allocated, it's returned through *pages, so it's incumbent on the
caller to free it. However, not all callers do.
Fix this by freeing the table and clearing *pages before returning an error
or 0. Note that iov_iter_extract_pages() and its subfunctions are allowed
to return 0 without returning an array (for instance if the iterator count
is 0).
Fixes: 7d58fe7310 ("iov_iter: Add a function to extract a page list from an iterator")
Closes: https://sashiko.dev/#/patchset/20260616100821.2062304-1-dhowells%40redhat.com
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://patch.msgid.link/20260625140640.3116900-8-dhowells@redhat.com
Reviewed-by: Christoph Hellwig <hch@lst.de>
cc: Paulo Alcantara <pc@manguebit.org>
cc: Matthew Wilcox <willy@infradead.org>
cc: Christoph Hellwig <hch@infradead.org>
cc: Jens Axboe <axboe@kernel.dk>
cc: netfs@lists.linux.dev
cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
In iov_iter_extract_xarray_pages(), if no pages are extracted because
there's a hole (or something otherwise unextractable) in the xarray, then
the calculation of maxsize at the end can go wrong if the starting offset
is not zero.
Fix this by returning 0 in such a case and freeing the page array if
allocated here rather than being passed in.
Note that in the near future, ITER_XARRAY should be removed.
Fixes: 7d58fe7310 ("iov_iter: Add a function to extract a page list from an iterator")
Link: https://sashiko.dev/#/patchset/20260608145432.681865-1-dhowells%40redhat.com
Link: https://sashiko.dev/#/patchset/20260616100821.2062304-1-dhowells%40redhat.com
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://patch.msgid.link/20260625140640.3116900-6-dhowells@redhat.com
Reviewed-by: Christoph Hellwig <hch@lst.de>
cc: Paulo Alcantara <pc@manguebit.org>
cc: Matthew Wilcox <willy@infradead.org>
cc: Christoph Hellwig <hch@infradead.org>
cc: Jens Axboe <axboe@kernel.dk>
cc: Mike Marshall <hubcap@omnibond.com>
cc: netfs@lists.linux.dev
cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
netfs_create_write_req() will skip caching if the fscache cookie is
disabled, but this is a problem because async cache object creation might
not have got far enough yet that has been enabled - thereby causing the
call to fscache_begin_write_operation() to be skipped.
Fix this by removing the checks on the cookie and delegating this to
fscache_begin_write_operation().
Fixes: 7b589a9b45 ("netfs: Fix handling of USE_PGPRIV2 and WRITE_TO_CACHE flags")
Closes: https://sashiko.dev/#/patchset/20260624115737.2964520-1-dhowells%40redhat.com
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://patch.msgid.link/20260625140640.3116900-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>
netfs_perform_write() buffers data by writing it into the pagecache for
later writeback. If the folio it wants to write to isn't present, it uses
"write streaming" in which is will store partial data in a non-uptodate,
but dirty folio.
However, when fscache is in use, this is a potential problem as writes to
the cache have to be aligned to the cache backend's DIO granularity, and so
netfs_perform_write() attempts to suppress write-streaming in such a case,
requiring the folio content to be fetched first unless the entire folio is
going to be overwritten. This allows the content to be written to the
cache too.
Unfortunately, the test netfs_perform_write() uses isn't correct because it
doesn't take into account the fact that the object lookup is asynchronous
and farmed off to a work queue, so there's a short window in which the
cache is doing a lookup but the test fails because the answer is undefined.
This can be triggered by the generic/464 xfstest, and causes a warning to
be emitted in cachefiles (in code not yet upstream) because it sees a write
that doesn't have its bounds rounded out to DIO alignment.
Fix this by changing the condition to whether FSCACHE_COOKIE_IS_CACHING is
set on a cookie rather than whether the cookie is marked enabled. Note
that this is really just a hint as to whether we allow write streaming or
not and no other aspects of the cookie or cache object are accessed.
Also apply the same fix to netfs_write_begin().
Reported-by: Marc Dionne <marc.dionne@auristor.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://patch.msgid.link/20260625140640.3116900-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>
The loop in exec_binprm() permits depth values 0 through 5, up to 5
successive binfmt rewrites (setting bprm->interpreter) until the 6th
one would fail on depth > 5 and return -ELOOP. The comment claimed 4
levels, which was wrong. Adjusting the code to allow only 4 rewrites
would be breaking userland, so fix the comment and not the code.
Reproducer (a chain of shebanged scripts followed by an ELF binary):
#!/bin/sh
tmp=$(mktemp -d)
echo $tmp
cd $tmp
mk () { echo $2 > $1; chmod +x $1; }
for i in $(seq 4); do
mk $i "#!$((i + 1))"
done
mk 5 '#!/bin/true'
./1 &&
echo '5 binfmt rewrites OK (1 -> 2 -> 3 -> 4 -> 5 -> /bin/true)'
mk 5 '#!6'
mk 6 '#!/bin/true'
./1 ||
echo '6 binfmt rewrites KO (1 -> 2 -> 3 -> 4 -> 5 -> 6 -> /bin/true)'
Signed-off-by: Alan Urmancheev <alan.urman@gmail.com>
Link: https://patch.msgid.link/20260623052322.74711-1-alan.urman@gmail.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
iomap: fix zero padding data issue in concurrent append writes
changed ioend accounting so that io_size tracks only valid data
within EOF. This trims io_size when a writeback range extends
past end_pos:
ioend->io_size += map_len;
if (ioend->io_offset + ioend->io_size > end_pos)
ioend->io_size = end_pos - ioend->io_offset;
However, if end_pos ends up below ioend->io_offset, the subtraction
becomes negative and is stored in size_t io_size, causing an unsigned
wrap to a huge value. This can happen when writeback continues past
byte-level EOF up to a block-aligned range, or when a concurrent
truncate shrinks the file after end_pos was sampled in
iomap_writeback_handle_eof().
A wrapped io_size can mislead append detection and corrupt
completion-time size handling, since filesystem end_io paths consume
io_size for decisions such as on-disk EOF updates and unwritten/COW
completion ranges.
Fix this by clamping io_size to zero when EOF has moved to or before
the ioend start offset. This preserves the original intent of trimming
io_size to valid in-EOF data while avoiding the underflow.
Fixes: 51d20d1dac ("iomap: fix zero padding data issue in concurrent append writes")
Suggested-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Morduan Zang <zhangdandan@uniontech.com>
Link: https://patch.msgid.link/9E38E2659B47DC2A+20260624062622.337469-1-zhangdandan@uniontech.com
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Since the rt and log block devices are closed in xfs_free_buftarg() the
buftarg owns the device file. The error unwind does not respect that:
when the log buftarg allocation fails, out_free_rtdev_targ frees the rt
buftarg - releasing rtdev_file - and then falls through to
out_close_rtdev and releases it a second time.
The unwind also leaves mp->m_rtdev_targp and mp->m_ddev_targp pointing
to the freed buftargs. The failed mount continues into
deactivate_locked_super() -> xfs_kill_sb() -> xfs_mount_free(), which
frees them again.
Clear the buftarg pointers once the unwind freed them and clear
rtdev_file once the rt buftarg owns it, so nothing is released twice.
Reachable when a buftarg allocation fails after the data buftarg was
set up: an I/O error in sync_blockdev() or an allocation failure in
xfs_init_buftarg() while mounting with external rt and log devices.
Link: https://patch.msgid.link/20260616-work-super-bdev_holder_global-v2-1-7df6b864028e@kernel.org
Fixes: 41233576e9 ("xfs: close the RT and log block devices in xfs_free_buftarg")
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
bpf_real_data_inode() must be usable from the bprm_check_security,
mmap_file and file_mprotect hooks for systemd's RestrictFilesystemAccess
BPF LSM program, so have it take a struct file instead of a dentry.
Amir Goldstein <amir73il@gmail.com> suggests:
While doing so, rename it from bpf_real_inode() to
bpf_real_data_inode(). For a regular file on a union/overlay
filesystem it resolves to the underlying inode that hosts the data,
but for a non-regular file it returns the overlay inode. The new name
makes the "inode hosting the data" intent explicit and avoids the
ambiguity of "the real inode backing a file". Document the
non-regular-file behavior in the kfunc too.
Both the signature change and the rename are safe because the kfunc
landed this cycle and has no released users.
Link: https://patch.msgid.link/20260623-work-bpf-real_inode-v2-1-8e8b57dd25f7@kernel.org
Fixes: 9af8c8a54f ("bpf: add bpf_real_inode() kfunc")
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
fill_from_part() computes the size of a directory entry in size_t but
stores it in a __u32. An entry length near U32_MAX wraps it to a small
value, bypasses the bounds check, and is then used to index the entry,
reading far past the directory part -- an out-of-bounds read that oopses
the kernel.
Compute the size as a u64 so it cannot truncate; the bounds check then
rejects the entry. The trailer is supplied by the userspace client.
Fixes: 480e3e532e ("orangefs: support very large directories")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
Link: https://patch.msgid.link/20260619-b4-disp-50d2bd59-v1-1-ce332969b4a2@proton.me
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
vxfs_bmap_typed() handles four typed-extent types and calls BUG() in
its default case, so an on-disk typed extent with any other type value
crashes the kernel. It is reachable from ioctl(FIBMAP) on a regular
file:
kernel BUG at fs/freevxfs/vxfs_bmap.c:230!
RIP: vxfs_bmap_typed fs/freevxfs/vxfs_bmap.c:230 [inline]
vxfs_bmap1+0x128a/0x12d0 fs/freevxfs/vxfs_bmap.c:257
Replace the BUG() with WARN_ON_ONCE() and return 0 -- the value
vxfs_bmap_typed() already returns on failure (and from the DEV4 case
above); vxfs_getblk() maps 0 to -EIO, so the ioctl fails cleanly.
Reported-by: Farhad Alemi <farhad.alemi@berkeley.edu>
Signed-off-by: Farhad Alemi <farhad.alemi@berkeley.edu>
Link: https://patch.msgid.link/CA+0ovChveuAwv=t15dr2m09E32bM48hHJxvfeEYZOhdNiEc9Tw@mail.gmail.com
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
David Howells <dhowells@redhat.com> says:
(1) Fix the CB.InitCallBackState3 service handler to handle an unknown
server (server pointer is NULL).
(2) Fix the clobbering of the default error code in
afs_extract_vl_addrs().
(3) Fix a NULL pointer in a trace point in afs_get_tree().
(4) Fix double netfs_inode initialisation in afs_root_iget().
(5) Fix setting of AS_RELEASE_ALWAYS for symlinks (and mountpoints) as
there's no release_folio function provided. The pagecache isn't used
by afs for symlinks and directories.
(6) Fix the order of inode init to avoid clobbering
NETFS_ICTX_SINGLE_NO_UPLOAD set on directories.
(7) Fix the release of op->more_files to Use kvfree().
(8) Fix erroneous seq |= 1 in volume lookup loop.
(9) Drop for duplicate server records when parsing DNS reply into the VL
server list (this is not strictly a bug fix, so could be punted to the
merge window).
(10) Fix malfunction in bulk lookup due to change in dir_emit() API added
to mask off DT_* flags for overlayfs on fuse.
(11) Fix misplaced inc of net->cells_outstanding causing netns destruction
hang.
(12) Fix reinitialisation of afs_vnode::lock_work. Not reinitialising it
after allocation seems to upset DEBUG_OBJECTS despite there being an
slab init-once handler provided.
(13) Fix callback service message parsers to pass through -EAGAIN when
insufficient data yet received.
(14) Switch to using scoped_seqlock_read() in volume lookup loop as a
follow up to (6).
(15) Fix leak of a volume we failed to get because its refcount had hit 0.
(16) Fix missing NULL pointer check in afs_break_some_callbacks().
(17) Fix leak of empty new vllist in afs_update_cell().
(18) Fix modifications of net->cells_dyn_ino to use locking; this requires
the use of preallocation as the allocation has to be done under
spinlock.
(19) Fix insertion into net->cells_dyn_ino to only add a new cell into the
IDR only after we've checked it's not a duplicate.
(20) Fix afs_insert_volume_into_cell() to set AFS_VOLUME_RM_TREE on the
old volume, not the new.
(21) Fix afs_extract_vlserver_list() to limit the string displayed in the
debug statement.
* patches from https://patch.msgid.link/20260622090856.2746629-1-dhowells@redhat.com: (23 commits)
afs: Fix unchecked-length string display in debug statement
afs: Fix the volume AFS_VOLUME_RM_TREE is set on
afs: Fix premature cell exposure through /afs
afs: Fix lack of locking around modifications of net->cells_dyn_ino
afs: Fix vllist leak
afs: Fix leak of ungot volume
afs: Fix missing NULL pointer check in afs_break_some_callbacks()
afs: Use scoped_seqlock_read() rather than manually doing seqlock stuff
afs: Fix callback service message parsers to pass through -EAGAIN
afs: Fix reinitialisation of the inode, in particular ->lock_work
afs: Fix misplaced inc of net->cells_outstanding
afs: Fix bulk lookup malfunction due to change in dir_emit() API
afs: check for duplicate servers in VL server list
afs: Remove erroneous seq |= 1 in volume lookup loop
afs: use kvfree() to free memory allocated by kvcalloc()
afs: Fix directory inode initialisation order
afs: Remove setting of AS_RELEASE_ALWAYS for symlinks and mountpoints
afs: Fix double netfs initialisation in afs_root_iget()
afs: fix NULL pointer dereference in afs_get_tree()
afs: Fix error code in afs_extract_vl_addrs()
...
Link: https://patch.msgid.link/20260622090856.2746629-1-dhowells@redhat.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
The FAT specification[1] (FAT Directory Structure -> "DIR_Name[0]") states:
If DIR_Name[0] == 0x00, then the directory entry is free (same as for
0xE5), and there are no allocated directory entries after this one
(all of the DIR_Name[0] bytes in all of the entries after this one
are also set to 0).
The special 0 value, rather than the 0xE5 value, indicates to FAT
file system driver code that the rest of the entries in this
directory do not need to be examined because they are all free.
Linux did not honour this. fat_get_entry() kept advancing past the 0x00
terminator; if the trailing on-disk slots were not zero-filled (buggy
formatters, read-only media written by other operating systems, on-disk
corruption) the driver surfaced arbitrary bytes as real directory
entries. On a typical affected image, `ls /mnt` returns ~150 bogus
entries with random binary names, multi-gigabyte sizes, dates ranging
from 1980 to 2106, and a flood of -EIO from stat().
Earlier attempts (v1..v3, see [2][3][4]) added `de->name[0] == 0` guards
at each call site. As Hirofumi pointed out on v3, those guards reject
the entry but fat_get_entry() has already advanced *pos past it; the
next readdir() resumes after the marker and walks straight back into
the garbage. His suggestion was to centralise the check.
This patch:
* Adds fat_get_entry_eod(), a small wrapper around fat_get_entry()
that returns -1 when name[0] == 0 and seeks *pos to dir->i_size.
Per spec every slot after the 0x00 marker is also zero, so jumping
to the end of the directory is correct: subsequent reads return -1
from fat_bmap() without re-fetching trailing zero slots, and
callers persisting *pos across invocations (notably readdir's
ctx->pos) keep reporting end-of-directory on re-entry.
* Converts the read/search paths to use the new wrapper:
fat_parse_long(), fat_search_long(), __fat_readdir(),
and fat_get_short_entry() -- the last covers
fat_get_dotdot_entry(), fat_dir_empty(), fat_subdirs(),
fat_scan(), and fat_scan_logstart() transitively.
* Leaves fat_add_entries() and __fat_remove_entries() on raw
fat_get_entry(): the write paths legitimately need to operate on
free/zero slots. fat_add_entries() additionally detects an
allocated entry past a 0x00 marker (the spec violation that
produces the garbage) and treats it as filesystem corruption:
fat_fs_error_ratelimit() is called -- which honours the configured
errors= mount option (panic / remount-ro / continue) -- and the
operation returns -EIO so we don't write fresh entries into an
already-corrupt directory.
[1] https://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/fatgen103.doc
[2] https://lore.kernel.org/lkml/20181207013410.7050-1-mcroce@redhat.com/
[3] https://lore.kernel.org/lkml/20181216231510.26854-1-mcroce@redhat.com/
[4] https://lore.kernel.org/lkml/20190201001408.7453-1-mcroce@redhat.com/
Reported-by: Timothy Redaelli <tredaelli@redhat.com>
Suggested-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: Matteo Croce <teknoraver@meta.com>
Link: https://patch.msgid.link/20260616163346.32603-1-technoboy85@gmail.com
Acked-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Forgot to update the comment when we changed the locking order.
Fixes: 162d064440 ("ovl: reorder ovl_want_write() after ovl_inode_lock()")
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Link: https://patch.msgid.link/20260609184656.1916631-1-amir73il@gmail.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
When start_creating() fails and returns -ENOMEM, it has already
released the parent directory lock in __start_dirop():
static struct dentry *__start_dirop(...)
{
...
inode_lock_nested(dir, I_MUTEX_PARENT);
dentry = lookup_one_qstr_excl(name, parent, lookup_flags);
if (IS_ERR(dentry))
inode_unlock(dir); <-- Lock released on error
return dentry;
}
However, the nomem_d_alloc error path in cachefiles_get_directory()
unconditionally calls inode_unlock(d_inode(dir)) again, causing a
double unlock that corrupts the rwsem state.
This is a leftover from commit 7ab96df840 which replaced manual
locking with start_creating() but failed to update the nomem_d_alloc
path (while correctly updating mkdir_error and lookup_error paths).
Fixes: 7ab96df840 ("VFS/nfsd/cachefiles/ovl: add start_creating() and end_creating()")
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
Link: https://patch.msgid.link/20260617085049.730789-1-zenghongling@kylinos.cn
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
minix_check_superblock() uses minix_blocks_needed() to verify that the
on-disk imap and zmap block counts are large enough for the advertised
inode and zone counts.
The helper currently performs DIV_ROUND_UP() in unsigned int arithmetic.
A Minix v3 image can set s_ninodes or s_zones near UINT_MAX so the
addition inside DIV_ROUND_UP() wraps to zero. That makes a zero imap/zmap
block count look valid, after which minix_fill_super() can dereference
s_imap[0] or s_zmap[0] even though no bitmap buffers were allocated.
Impact: mounting a crafted Minix v3 image whose s_ninodes or s_zones is
near UINT_MAX makes minix_check_superblock() accept a zero bitmap-block
count and minix_fill_super() dereference s_imap[0]/s_zmap[0], panicking
the kernel.
The divisor is the bitmap capacity in bits, blocksize * 8, which is
always a power of two: minix_fill_super() obtains the block size through
sb_set_blocksize(), and blk_validate_block_size() rejects any size that
is not a power of two. Use DIV_ROUND_UP_POW2(), which divides before
adding the round-up term and so cannot overflow for a power-of-two
divisor.
Fixes: 8c97a6ddc9 ("minix: Add required sanity checking to minix_check_superblock()")
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
Link: https://patch.msgid.link/20260618143922.3066874-1-michael.bommarito@gmail.com
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
ovl_copy_up_tmpfile() stores the disconnected O_TMPFILE dentry as the
overlay's upper dentry reference via ovl_inode_update(). vfs_tmpfile()
allocated this dentry via d_alloc(parentpath->dentry, &slash_name), so
d_name is "/" and d_parent is c->workdir. Local upper filesystems
(ext4, btrfs, xfs, ...) immediately rename it to "#<inum>" via
d_mark_tmpfile() inside their ->tmpfile() op; FUSE and virtiofs do
not, so both fields stay that way. Neither identifies the destination
directory and filename where ovl_do_link() actually linked the file.
When the upper filesystem implements ->d_revalidate() (e.g. FUSE or
virtiofs), ovl_revalidate_real() calls it with the dentry's parent
inode and a snapshot of d_name. The server tries to look up "/" inside
c->workdir, fails, and overlayfs reports -ESTALE.
This causes persistent ESTALE errors for any file that was copied up via
the tmpfile path, breaking dpkg, apt, and other tools that do
rename-over-existing on overlayfs with a FUSE/virtiofs upper.
Before commit 6b52243f63 ("ovl: fold copy-up helpers into callers"),
the tmpfile copy-up path used a dedicated helper ovl_link_tmpfile()
that captured the linked destination dentry returned by ovl_do_link():
err = ovl_do_link(temp, udir, upper);
...
if (!err)
*newdentry = dget(upper);
and published it via ovl_inode_update(d_inode(c->dentry), newdentry).
The fold inlined ovl_do_link() into ovl_copy_up_tmpfile() but dropped
the dget(upper) capture, and rewrote the publish line as
ovl_inode_update(d_inode(c->dentry), dget(temp)) — where temp is the
disconnected O_TMPFILE dentry.
Fix by keeping a reference to the linked destination dentry after
ovl_do_link() succeeds, and publishing that dentry at the existing
ovl_inode_update() call site. The non-tmpfile/workdir path continues to
publish the renamed temporary dentry.
Reproducer:
- Mount overlayfs with virtiofs (or a FUSE fs whose server advertises
FUSE_TMPFILE) as upper
- Run: dpkg -i <any .deb>
- Observe: "error installing new file '...': Stale file handle"
Fixes: 6b52243f63 ("ovl: fold copy-up helpers into callers")
Cc: stable@vger.kernel.org # v4.20+
Signed-off-by: Souvik Banerjee <souvik@amlalabs.com>
Link: https://patch.msgid.link/20260501232735.2610824-1-souvik@amlalabs.com
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
proc_register() increments the parent directory's link count for every
entry it registers, while remove_proc_entry() and remove_proc_subtree()
decrement it only when the removed entry is a directory. Regular files
thus inflate the parent's count while they exist, and leak one link
permanently on every create and remove cycle.
For example, /proc/bus/pci/00 with twenty-two device files and no
subdirectories reports nlink 24 instead of 2, and SR-IOV VF enable
and disable cycles, each creating and removing the VF config space
entries under /proc/bus/pci/<bus>, inflate the link count of that
directory without bound.
Before commit e06689bf57 ("proc: change ->nlink under
proc_subdir_lock"), the increment lived in proc_mkdir_data() and
proc_create_mount_point(), and was therefore applied only to
directories. Moving it into proc_register() to bring it under
proc_subdir_lock dropped the S_ISDIR check.
Thus, move the nlink accounting into pde_subdir_insert() and
pde_erase(), only updating it for directories in both, so the link
count is always changed together with the directory entry itself.
Fixes: e06689bf57 ("proc: change ->nlink under proc_subdir_lock")
Cc: stable@vger.kernel.org # v5.5+
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Link: https://patch.msgid.link/20260613211005.921692-1-kwilczynski@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
If bio_iov_iter_get_pages() or the bounce helper succeeds but builds a
short bio, the REQ_ATOMIC size check rejects it before submission. The
old error path only dropped the bio reference, leaving any pages already
attached to the bio unreleased.
Release or unbounce the pages before falling through to out_put_bio on
this error path.
This bug was reported by sashiko:
https://sashiko.dev/#/patchset/20260608073134.95964-1-changfengnan%40bytedance.com
Fixes: 9e0933c21c ("fs: iomap: Atomic write support")
Signed-off-by: Fengnan Chang <changfengnan@bytedance.com>
Link: https://patch.msgid.link/20260612044041.10677-1-changfengnan@bytedance.com
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
I talked to Hans de Goede about two weeks ago in person. He expressed he
would rather have someone else maintain vboxsf and was thinking about
orphaning it. Since I am already doing filesystem stuff anyway, I am
fine with doing this. (vboxsf is a thin layer between the vfs and the
Virtual Box guest device driver).
I have no major plans for vboxsf, but I do want to support passing
physical addresses to the host; the communication protocol seems to
allow for it and it would mean we can get rid of some kmap calls.
Signed-off-by: Jori Koolstra <jkoolstra@xs4all.nl>
Link: https://patch.msgid.link/20260614191040.3007723-1-jkoolstra@xs4all.nl
Acked-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Christian Brauner <brauner@kernel.org> says:
vfs_tmpfile() is the only object-creation path in the VFS that never
checked whether the caller's fsuid and fsgid map into the filesystem.
On an idmapped mount whose idmapping does not cover the caller's
fs{u,g}id, the ->tmpfile() instance initializes the new inode through
inode_init_owner(), where mapped_fsuid()/mapped_fsgid() return
INVALID_UID/INVALID_GID. The tmpfile ends up owned by (uid_t)-1, and
because it is created I_LINKABLE it can subsequently be spliced into the
namespace with linkat(2).
Every other creation path already refuses this: may_o_create() (O_CREAT)
and may_create_dentry() (mkdir, mknod, symlink, link) bail out with
-EOVERFLOW via fsuidgid_has_mapping() precisely so that an object cannot
be created with an owner the filesystem cannot represent. O_TMPFILE is
no exception and must hold the same guarantee.
Patch 1 adds the missing fsuidgid_has_mapping() check to vfs_tmpfile().
It is a no-op on non-idmapped mounts -- there the caller's fs{u,g}id
always map in the superblock's user namespace -- and only takes effect
on an idmapped mount that does not map the caller. It applies to every
filesystem that sets FS_ALLOW_IDMAP and implements ->tmpfile() (tmpfs,
ext4, btrfs, xfs, f2fs, ...), and to overlayfs, whose upper-layer
tmpfile creation funnels through vfs_tmpfile() via
backing_tmpfile_open().
Patch 2 adds a selftest that idmaps a detached tmpfs mount and checks
both directions: an unmapped caller is refused with -EOVERFLOW, while a
mapped caller can create an O_TMPFILE, link it into the namespace, and
have its ownership round-trip through the mount idmap.
* patches from https://patch.msgid.link/20260615-work-idmapped-tmpfile-v1-0-754a94d81f83@kernel.org:
selftests/filesystems: test O_TMPFILE creation on idmapped mounts
fs: refuse O_TMPFILE creation with an unmapped fsuid or fsgid
Link: https://patch.msgid.link/20260615-work-idmapped-tmpfile-v1-0-754a94d81f83@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
AFS cell records are prematurely exposured through the /afs dynamic root by
virtue of adding them immediately to the net->cells_dyn_ino IDR when the
cell is allocated rather than when it is added to the lookup tree. This
allows a candidate record to be accessed, even if it's actually a duplicate
or not published yet.
Fix this by not adding the cell to cells_dyn_ino until it's confirmed
non-duplicate and is being published. A flag is then used to record
whether it is added to the IDR to make removal from the IDR conditional.
Closes: https://sashiko.dev/#/patchset/20260618155141.2513212-1-dhowells%40redhat.com
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://patch.msgid.link/20260622090856.2746629-20-dhowells@redhat.com
Fixes: 1d0b929fc0 ("afs: Change dynroot to create contents on demand")
cc: Marc Dionne <marc.dionne@auristor.com>
cc: linux-afs@lists.infradead.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
The AFS filesystem client uses an rxrpc server to listen for callback
notifications. Each callback call type handler has a delivery function
that parses the incoming request stream, and this should return -EAGAIN the
last packet hasn't yet been seen, but all currently queued received data is
consumed. afs_extract_data() does this, but the -EAGAIN return is switched
to 0 inadvertantly
Fix callback service message parsers to pass through -EAGAIN
Fixes: d001648ec7 ("rxrpc: Don't expose skbs to in-kernel users [ver #2]")
Closes: https://sashiko.dev/#/patchset/20260609081738.770127-1-dhowells%40redhat.com
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://patch.msgid.link/20260622090856.2746629-14-dhowells@redhat.com
cc: Marc Dionne <marc.dionne@auristor.com>
cc: linux-afs@lists.infradead.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
It seems that initalising afs_vnode::lock_work a single time in the slab's
init function isn't sufficient for work_structs. This results in the
DEBUG_OBJECTS debugging stuff producing a warning occasionally when running
the generic/131 xfstest:
ODEBUG: activate not available (active state 0) object: 0000000016d8760f object type: work_struct hint: afs_lock_work+0x0/0x220
WARNING: lib/debugobjects.c:629 at debug_print_object+0x4b/0x90, CPU#3: locktest/7695
...
CPU: 3 UID: 0 PID: 7695 Comm: locktest Tainted: G S 7.1.0-build3+ #2771 PREEMPT
...
RIP: 0010:debug_print_object+0x65/0x90
...
Call Trace:
<TASK>
? __pfx_afs_lock_work+0x10/0x10
debug_object_activate+0x122/0x170
insert_work+0x25/0x60
__queue_work+0x2e0/0x340
queue_delayed_work_on+0x48/0x70
afs_fl_release_private+0x57/0x70
locks_release_private+0x5c/0xa0
locks_free_lock+0xe/0x20
posix_lock_inode+0x55f/0x5b0
locks_lock_inode_wait+0x81/0x140
? file_write_and_wait_range+0x50/0x70
afs_lock+0xcd/0x110
fcntl_setlk+0x10d/0x260
do_fcntl+0x24e/0x5b0
__do_sys_fcntl+0x6a/0x90
do_syscall_64+0x11e/0x310
entry_SYSCALL_64_after_hwframe+0x71/0x79
Fix this by reinitialising ->lock_work after allocating an inode.
Also, flush ->lock_work when the inode is being evicted to make sure it's
not still running.
Fixes: e8d6c55412 ("AFS: implement file locking")
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://patch.msgid.link/20260622090856.2746629-13-dhowells@redhat.com
cc: Marc Dionne <marc.dionne@auristor.com>
cc: Thomas Gleixner <tglx@kernel.org>
cc: linux-afs@lists.infradead.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Fix net->cells_outstanding being incremented before the check for failure
of idr_alloc_cyclic(), leaving the count incremented on error.
Fixes: 88c853c3f5 ("afs: Fix cell refcounting by splitting the usage counter")
Reported-by: Hillf Danton <hdanton@sina.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://patch.msgid.link/20260622090856.2746629-12-dhowells@redhat.com
cc: Marc Dionne <marc.dionne@auristor.com>
cc: linux-afs@lists.infradead.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
afs_do_lookup() and afs_do_lookup_one() use the same directory parsing code
as afs_readdir() and were supplying alternative dir_context actors to
retrieve dirents, but because lookup needs the vnode's uniquifier as part
of the reference, but not the DT flags, the uniquifier was being passed in
the dt flags argument to the lookup actors.
Unfortunately, commit c644bce62b, added to fix overlayfs with fuse, broke
this by masking off part of the uniquifier. This doesn't matter enough to
be directly noticeable, instead causing bulk advance inode lookups to fail
(which are retried later) and may cause dir revalidation to malfunction if
the uniquifier is changed by masking.
Fix this by making the afs directory parsing code take special ->actor
values of AFS_LOOKUP or AFS_LOOKUP_ONE instead that tell it to call
afs_lookup_filldir() or afs_lookup_one_filldir() directly rather than going
through dir_emit(). dir_emit() is still used for readdir.
Fixes: c644bce62b ("readdir: require opt-in for d_type flags")
Reported-by: Marc Dionne <marc.dionne@auristor.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://patch.msgid.link/20260622090856.2746629-11-dhowells@redhat.com
cc: Amir Goldstein <amir73il@gmail.com>
cc: linux-afs@lists.infradead.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
The DNS response may contain the same server more than once. Check for
duplicates by name and port before inserting into the list to avoid
duplicate entries.
Addresses the TODO comment in afs_extract_vlserver_list().
Signed-off-by: Yuto Ohnuki <ytohnuki@amazon.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://patch.msgid.link/20260622090856.2746629-10-dhowells@redhat.com
cc: Marc Dionne <marc.dionne@auristor.com>
cc: linux-afs@lists.infradead.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
The `seq |= 1` operation in the volume lookup loop is incorrect because:
seq is already incremented at start, making it odd in next iteration
which triggers lock, but The `|= 1` operation causes seq to be even
and unintended lockless operation
Remove this erroneous operation to maintain proper lock sequencing.
Fixes: 32222f0978 ("afs: Apply server breaks to mmap'd files in the call processor")
Signed-off-by: Li RongQing <lirongqing@baidu.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://patch.msgid.link/20260622090856.2746629-9-dhowells@redhat.com
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
cc: Marc Dionne <marc.dionne@auristor.com>
cc: linux-afs@lists.infradead.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
op->more_files is allocated with kvcalloc() but released via
afs_put_operation(), which uses kfree() internally. This mismach prevents
the resource from being released properly and may lead to undefined
behavior.
Fix this by using kvfree() to free op->more_files to match its allocation
method.
Fixes: e49c7b2f6d ("afs: Build an abstraction around an "operation" concept")
Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://patch.msgid.link/20260622090856.2746629-8-dhowells@redhat.com
cc: Marc Dionne <marc.dionne@auristor.com>
cc: linux-afs@lists.infradead.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
