linux.git/fs/exfat, branch v6.8

Merge tag 'exfat-for-6.8-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat

2024-03-01T20:22:30+00:00

Pull exfat fix from Namjae Jeon:

 - Fix ftruncate failure when allocating non-contiguous clusters

* tag 'exfat-for-6.8-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat:
  exfat: fix appending discontinuous clusters to empty file

Merge tag 'pull-fixes.pathwalk-rcu-2' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs

2024-02-25T17:29:05+00:00

Pull RCU pathwalk fixes from Al Viro:
 "We still have some races in filesystem methods when exposed to RCU
  pathwalk. This series is a result of code audit (the second round of
  it) and it should deal with most of that stuff.

  Still pending: ntfs3 ->d_hash()/->d_compare() and ceph_d_revalidate().
  Up to maintainers (a note for NTFS folks - when documentation says
  that a method may not block, it *does* imply that blocking allocations
  are to be avoided. Really)"

[ More explanations for people who aren't familiar with the vagaries of
  RCU path walking: most of it is hidden from filesystems, but if a
  filesystem actively participates in the low-level path walking it
  needs to make sure the fields involved in that walk are RCU-safe.

  That "actively participate in low-level path walking" includes things
  like having its own ->d_hash()/->d_compare() routines, or by having
  its own directory permission function that doesn't just use the common
  helpers.  Having a ->d_revalidate() function will also have this issue.

  Note that instead of making everything RCU safe you can also choose to
  abort the RCU pathwalk if your operation cannot be done safely under
  RCU, but that obviously comes with a performance penalty. One common
  pattern is to allow the simple cases under RCU, and abort only if you
  need to do something more complicated.

  So not everything needs to be RCU-safe, and things like the inode etc
  that the VFS itself maintains obviously already are. But these fixes
  tend to be about properly RCU-delaying things like ->s_fs_info that
  are maintained by the filesystem and that got potentially released too
  early.   - Linus ]

* tag 'pull-fixes.pathwalk-rcu-2' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  ext4_get_link(): fix breakage in RCU mode
  cifs_get_link(): bail out in unsafe case
  fuse: fix UAF in rcu pathwalks
  procfs: make freeing proc_fs_info rcu-delayed
  procfs: move dropping pde and pid from ->evict_inode() to ->free_inode()
  nfs: fix UAF on pathwalk running into umount
  nfs: make nfs_set_verifier() safe for use in RCU pathwalk
  afs: fix __afs_break_callback() / afs_drop_open_mmap() race
  hfsplus: switch to rcu-delayed unloading of nls and freeing ->s_fs_info
  exfat: move freeing sbi, upcase table and dropping nls into rcu-delayed helper
  affs: free affs_sb_info with kfree_rcu()
  rcu pathwalk: prevent bogus hard errors from may_lookup()
  fs/super.c: don't drop ->s_user_ns until we free struct super_block itself

exfat: move freeing sbi, upcase table and dropping nls into rcu-delayed helper

2024-02-25T07:10:31+00:00

That stuff can be accessed by ->d_hash()/->d_compare(); as it is, we have
a hard-to-hit UAF if rcu pathwalk manages to get into ->d_hash() on a filesystem
that is in process of getting shut down.

Besides, having nls and upcase table cleanup moved from ->put_super() towards
the place where sbi is freed makes for simpler failure exits.

Acked-by: Christian Brauner 
Signed-off-by: Al Viro

exfat: fix appending discontinuous clusters to empty file

2024-02-18T05:41:18+00:00

Eric Hong found that when using ftruncate to expand an empty file,
exfat_ent_set() will fail if discontinuous clusters are allocated.
The reason is that the empty file does not have a cluster chain,
but exfat_ent_set() attempts to append the newly allocated cluster
to the cluster chain. In addition, exfat_find_last_cluster() only
supports finding the last cluster in a non-empty file.

So this commit adds a check whether the file is empty. If the file
is empty, exfat_find_last_cluster() and exfat_ent_set() are no longer
called as they do not need to be called.

Fixes: f55c096f62f1 ("exfat: do not zero the extended part")
Reported-by: Eric Hong 
Signed-off-by: Yuezhang Mo 
Signed-off-by: Namjae Jeon

exfat: fix zero the unwritten part for dio read

2024-01-18T14:01:51+00:00

For dio read, bio will be leave in flight when a successful partial
aio read have been setup, blockdev_direct_IO() will return
-EIOCBQUEUED. In the case, iter->iov_offset will be not advanced,
the oops reported by syzbot will occur if revert iter->iov_offset
with iov_iter_revert(). The unwritten part had been zeroed by aio
read, so there is no need to zero it in dio read.

Reported-by: syzbot+fd404f6b03a58e8bc403@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=fd404f6b03a58e8bc403
Fixes: 11a347fb6cef ("exfat: change to get file size from DataLength")
Signed-off-by: Yuezhang Mo 
Signed-off-by: Namjae Jeon

exfat: do not zero the extended part

2024-01-08T12:57:22+00:00

Since the read operation beyond the ValidDataLength returns zero,
if we just extend the size of the file, we don't need to zero the
extended part, but only change the DataLength without changing
the ValidDataLength.

Signed-off-by: Yuezhang Mo 
Reviewed-by: Andy Wu 
Reviewed-by: Aoyama Wataru 
Reviewed-by: Sungjong Seo 
Signed-off-by: Namjae Jeon

exfat: change to get file size from DataLength

2024-01-08T12:57:22+00:00

In stream extension directory entry, the ValidDataLength
field describes how far into the data stream user data has
been written, and the DataLength field describes the file
size.

Signed-off-by: Yuezhang Mo 
Reviewed-by: Andy Wu 
Reviewed-by: Aoyama Wataru 
Reviewed-by: Sungjong Seo 
Signed-off-by: Namjae Jeon

exfat: using ffs instead of internal logic

2024-01-08T12:57:21+00:00

Replaced the internal table lookup algorithm with ffs of
the bitops library with better performance.

Use it to increase the single processing length of the
exfat_find_free_bitmap function, from single-byte search to long type.

Signed-off-by: John Sanpe 
Acked-by: Sungjong Seo 
Signed-off-by: Namjae Jeon

exfat: using hweight instead of internal logic

2024-01-08T12:57:21+00:00

Replace the internal table lookup algorithm with the hweight
library, which has instruction set acceleration capabilities.

Use it to increase the length of a single calculation of
the exfat_find_free_bitmap function to the long type.

Signed-off-by: John Sanpe 
Acked-by: Sungjong Seo 
Signed-off-by: Namjae Jeon

exfat: fix ctime is not updated

2023-11-03T13:24:11+00:00

Commit 4c72a36edd54 ("exfat: convert to new timestamp accessors")
removed attr_copy() from exfat_set_attr().
It causes xfstests generic/221 to fail. In xfstests generic/221,
it tests ctime should be updated even if futimens() update atime
only. But in this case, ctime will not be updated if attr_copy()
is removed.

attr_copy() may also update other attributes, and removing it may
cause other bugs, so this commit restores to call attr_copy() in
exfat_set_attr().

Fixes: 4c72a36edd54 ("exfat: convert to new timestamp accessors")
Signed-off-by: Yuezhang Mo 
Reviewed-by: Andy Wu 
Reviewed-by: Aoyama Wataru 
Reviewed-by: Sungjong Seo 
Signed-off-by: Namjae Jeon