<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/fs/exfat, branch v6.19.11</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.19.11</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.19.11'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2025-12-03T01:00:17+00:00</updated>
<entry>
<title>exfat: fix remount failure in different process environments</title>
<updated>2025-12-03T01:00:17+00:00</updated>
<author>
<name>Yuezhang Mo</name>
<email>Yuezhang.Mo@sony.com</email>
</author>
<published>2025-11-28T09:51:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=51fc7b4ce10ccab8ea5e4876bcdc42cf5202a0ef'/>
<id>urn:sha1:51fc7b4ce10ccab8ea5e4876bcdc42cf5202a0ef</id>
<content type='text'>
The kernel test robot reported that the exFAT remount operation
failed. The reason for the failure was that the process's umask
is different between mount and remount, causing fs_fmask and
fs_dmask are changed.

Potentially, both gid and uid may also be changed. Therefore, when
initializing fs_context for remount, inherit these mount options
from the options used during mount.

Reported-by: kernel test robot &lt;oliver.sang@intel.com&gt;
Closes: https://lore.kernel.org/oe-lkp/202511251637.81670f5c-lkp@intel.com
Signed-off-by: Yuezhang Mo &lt;Yuezhang.Mo@sony.com&gt;
Signed-off-by: Namjae Jeon &lt;linkinjeon@kernel.org&gt;
</content>
</entry>
<entry>
<title>exfat: fix divide-by-zero in exfat_allocate_bitmap</title>
<updated>2025-12-03T01:00:16+00:00</updated>
<author>
<name>Namjae Jeon</name>
<email>linkinjeon@kernel.org</email>
</author>
<published>2025-11-18T02:10:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d70a5804c563b5e34825353ba9927509df709651'/>
<id>urn:sha1:d70a5804c563b5e34825353ba9927509df709651</id>
<content type='text'>
The variable max_ra_count can be 0 in exfat_allocate_bitmap(),
which causes a divide-by-zero error in the subsequent modulo operation
(i % max_ra_count), leading to a system crash.
When max_ra_count is 0, it means that readahead is not used. This patch
load the bitmap without readahead.

Fixes: 9fd688678dd8 ("exfat: optimize allocation bitmap loading time")
Reported-by: Jiaming Zhang &lt;r772577952@gmail.com&gt;
Signed-off-by: Namjae Jeon &lt;linkinjeon@kernel.org&gt;
</content>
</entry>
<entry>
<title>exfat: validate the cluster bitmap bits of directory</title>
<updated>2025-12-03T01:00:16+00:00</updated>
<author>
<name>Namjae Jeon</name>
<email>linkinjeon@kernel.org</email>
</author>
<published>2025-11-12T00:42:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=866cba3675416c6cf446acb25d7c700eead1420e'/>
<id>urn:sha1:866cba3675416c6cf446acb25d7c700eead1420e</id>
<content type='text'>
Syzbot created this issue by testing an image that did not have the root
cluster bitmap bit marked. After accessing a file through the root
directory via exfat_lookup, when creating a file again with mkdir,
the root cluster bit can be allocated for direcotry, which can cause
the root cluster to be zeroed out and the same entry can be allocated
in the same cluster. This patch improved this issue by adding
exfat_test_bitmap to validate the cluster bits of the root directory
and directory. And the first cluster bit of the root directory should
never be unset except when storage is corrupted. This bit is set to
allow operations after mount.

Reported-by: syzbot+5216036fc59c43d1ee02@syzkaller.appspotmail.com
Tested-by: syzbot+5216036fc59c43d1ee02@syzkaller.appspotmail.com
Reviewed-by: Sungjong Seo &lt;sj1557.seo@samsung.com&gt;
Reviewed-by: Yuezhang Mo &lt;Yuezhang.Mo@sony.com&gt;
Signed-off-by: Namjae Jeon &lt;linkinjeon@kernel.org&gt;
</content>
</entry>
<entry>
<title>exfat: zero out post-EOF page cache on file extension</title>
<updated>2025-12-03T01:00:16+00:00</updated>
<author>
<name>Yuezhang Mo</name>
<email>Yuezhang.Mo@sony.com</email>
</author>
<published>2025-10-27T09:03:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4e163c39dd4e70fcdce948b8774d96e0482b4a11'/>
<id>urn:sha1:4e163c39dd4e70fcdce948b8774d96e0482b4a11</id>
<content type='text'>
xfstests generic/363 was failing due to unzeroed post-EOF page
cache that allowed mmap writes beyond EOF to become visible
after file extension.

For example, in following xfs_io sequence, 0x22 should not be
written to the file but would become visible after the extension:

  xfs_io -f -t -c "pwrite -S 0x11 0 8" \
    -c "mmap 0 4096" \
    -c "mwrite -S 0x22 32 32" \
    -c "munmap" \
    -c "pwrite -S 0x33 512 32" \
    $testfile

This violates the expected behavior where writes beyond EOF via
mmap should not persist after the file is extended. Instead, the
extended region should contain zeros.

Fix this by using truncate_pagecache() to truncate the page cache
after the current EOF when extending the file.

Signed-off-by: Yuezhang Mo &lt;Yuezhang.Mo@sony.com&gt;
Signed-off-by: Namjae Jeon &lt;linkinjeon@kernel.org&gt;
</content>
</entry>
<entry>
<title>exfat: fix refcount leak in exfat_find</title>
<updated>2025-12-03T01:00:16+00:00</updated>
<author>
<name>Shuhao Fu</name>
<email>sfual@cse.ust.hk</email>
</author>
<published>2025-10-21T08:42:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9aee8de970f18c2aaaa348e3de86c38e2d956c1d'/>
<id>urn:sha1:9aee8de970f18c2aaaa348e3de86c38e2d956c1d</id>
<content type='text'>
Fix refcount leaks in `exfat_find` related to `exfat_get_dentry_set`.

Function `exfat_get_dentry_set` would increase the reference counter of
`es-&gt;bh` on success. Therefore, `exfat_put_dentry_set` must be called
after `exfat_get_dentry_set` to ensure refcount consistency. This patch
relocate two checks to avoid possible leaks.

Fixes: 82ebecdc74ff ("exfat: fix improper check of dentry.stream.valid_size")
Fixes: 13940cef9549 ("exfat: add a check for invalid data size")
Signed-off-by: Shuhao Fu &lt;sfual@cse.ust.hk&gt;
Reviewed-by: Yuezhang Mo &lt;Yuezhang.Mo@sony.com&gt;
Signed-off-by: Namjae Jeon &lt;linkinjeon@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'vfs-6.18-rc7.fixes' of gitolite.kernel.org:pub/scm/linux/kernel/git/vfs/vfs</title>
<updated>2025-11-17T17:11:27+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2025-11-17T17:11:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e7c375b181600caf135cfd03eadbc45eb530f2cb'/>
<id>urn:sha1:e7c375b181600caf135cfd03eadbc45eb530f2cb</id>
<content type='text'>
Pull vfs fixes from Christian Brauner:

 - Fix unitialized variable in statmount_string()

 - Fix hostfs mounting when passing host root during boot

 - Fix dynamic lookup to fail on cell lookup failure

 - Fix missing file type when reading bfs inodes from disk

 - Enforce checking of sb_min_blocksize() calls and update all callers
   accordingly

 - Restore write access before closing files opened by open_exec() in
   binfmt_misc

 - Always freeze efivarfs during suspend/hibernate cycles

 - Fix statmount()'s and listmount()'s grab_requested_mnt_ns() helper to
   actually allow mount namespace file descriptor in addition to mount
   namespace ids

 - Fix tmpfs remount when noswap is specified

 - Switch Landlock to iput_not_last() to remove false-positives from
   might_sleep() annotations in iput()

 - Remove dead node_to_mnt_ns() code

 - Ensure that per-queue kobjects are successfully created

* tag 'vfs-6.18-rc7.fixes' of gitolite.kernel.org:pub/scm/linux/kernel/git/vfs/vfs:
  landlock: fix splats from iput() after it started calling might_sleep()
  fs: add iput_not_last()
  shmem: fix tmpfs reconfiguration (remount) when noswap is set
  fs/namespace: correctly handle errors returned by grab_requested_mnt_ns
  power: always freeze efivarfs
  binfmt_misc: restore write access before closing files opened by open_exec()
  block: add __must_check attribute to sb_min_blocksize()
  virtio-fs: fix incorrect check for fsvq-&gt;kobj
  xfs: check the return value of sb_min_blocksize() in xfs_fs_fill_super
  isofs: check the return value of sb_min_blocksize() in isofs_fill_super
  exfat: check return value of sb_min_blocksize in exfat_read_boot_sector
  vfat: fix missing sb_min_blocksize() return value checks
  mnt: Remove dead code which might prevent from building
  bfs: Reconstruct file type when loading from disk
  afs: Fix dynamic lookup to fail on cell lookup failure
  hostfs: Fix only passing host root in boot stage with new mount
  fs: Fix uninitialized 'offp' in statmount_string()
</content>
</entry>
<entry>
<title>exfat: check return value of sb_min_blocksize in exfat_read_boot_sector</title>
<updated>2025-11-05T13:00:16+00:00</updated>
<author>
<name>Yongpeng Yang</name>
<email>yangyongpeng@xiaomi.com</email>
</author>
<published>2025-11-04T12:50:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f2c1f631630e01821fe4c3fdf6077bc7a8284f82'/>
<id>urn:sha1:f2c1f631630e01821fe4c3fdf6077bc7a8284f82</id>
<content type='text'>
sb_min_blocksize() may return 0. Check its return value to avoid
accessing the filesystem super block when sb-&gt;s_blocksize is 0.

Cc: stable@vger.kernel.org # v6.15
Fixes: 719c1e1829166d ("exfat: add super block operations")
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Yongpeng Yang &lt;yangyongpeng@xiaomi.com&gt;
Link: https://patch.msgid.link/20251104125009.2111925-3-yangyongpeng.storage@gmail.com
Signed-off-by: Christian Brauner &lt;brauner@kernel.org&gt;
</content>
</entry>
<entry>
<title>exfat: fix out-of-bounds in exfat_nls_to_ucs2()</title>
<updated>2025-10-15T08:53:20+00:00</updated>
<author>
<name>Jeongjun Park</name>
<email>aha310510@gmail.com</email>
</author>
<published>2025-10-15T07:34:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2d8636119b92970ba135c3c4da87d24dbfdeb8ca'/>
<id>urn:sha1:2d8636119b92970ba135c3c4da87d24dbfdeb8ca</id>
<content type='text'>
Since the len argument value passed to exfat_ioctl_set_volume_label()
from exfat_nls_to_utf16() is passed 1 too large, an out-of-bounds read
occurs when dereferencing p_cstring in exfat_nls_to_ucs2() later.

And because of the NLS_NAME_OVERLEN macro, another error occurs when
creating a file with a period at the end using utf8 and other iocharsets.

So to avoid this, you should remove the code that uses NLS_NAME_OVERLEN
macro and make the len argument value be the length of the label string,
but with a maximum length of FSLABEL_MAX - 1.

Reported-by: syzbot+98cc76a76de46b3714d4@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=98cc76a76de46b3714d4
Fixes: d01579d590f7 ("exfat: Add support for FS_IOC_{GET,SET}FSLABEL")
Suggested-by: Pali Rohár &lt;pali@kernel.org&gt;
Signed-off-by: Jeongjun Park &lt;aha310510@gmail.com&gt;
Signed-off-by: Namjae Jeon &lt;linkinjeon@kernel.org&gt;
</content>
</entry>
<entry>
<title>exfat: fix improper check of dentry.stream.valid_size</title>
<updated>2025-10-15T05:37:21+00:00</updated>
<author>
<name>Jaehun Gou</name>
<email>p22gone@gmail.com</email>
</author>
<published>2025-10-14T13:01:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=82ebecdc74ff555daf70b811d854b1f32a296bea'/>
<id>urn:sha1:82ebecdc74ff555daf70b811d854b1f32a296bea</id>
<content type='text'>
We found an infinite loop bug in the exFAT file system that can lead to a
Denial-of-Service (DoS) condition. When a dentry in an exFAT filesystem is
malformed, the following system calls — SYS_openat, SYS_ftruncate, and
SYS_pwrite64 — can cause the kernel to hang.

Root cause analysis shows that the size validation code in exfat_find()
does not check whether dentry.stream.valid_size is negative. As a result,
the system calls mentioned above can succeed and eventually trigger the DoS
issue.

This patch adds a check for negative dentry.stream.valid_size to prevent
this vulnerability.

Co-developed-by: Seunghun Han &lt;kkamagui@gmail.com&gt;
Signed-off-by: Seunghun Han &lt;kkamagui@gmail.com&gt;
Co-developed-by: Jihoon Kwon &lt;jimmyxyz010315@gmail.com&gt;
Signed-off-by: Jihoon Kwon &lt;jimmyxyz010315@gmail.com&gt;
Signed-off-by: Jaehun Gou &lt;p22gone@gmail.com&gt;
Signed-off-by: Namjae Jeon &lt;linkinjeon@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'exfat-for-6.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat</title>
<updated>2025-10-03T21:02:53+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2025-10-03T21:02:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f0712c203862b00139b34fcbb1710b479af2b101'/>
<id>urn:sha1:f0712c203862b00139b34fcbb1710b479af2b101</id>
<content type='text'>
Pull exfat updates from Namjae Jeon:

 - Add support for FS_IOC_{GET,SET}FSLABEL ioctl

 - Two small clean-up patches

 - Optimizes allocation bitmap loading time on large partitions with
   small cluster sizes

 - Allow changes for discard, zero_size_dir, and errors options via
   remount

 - Validate that the clusters used for the allocation bitmap are
   correctly marked as in-use during mount, preventing potential data
   corruption from reallocating the bitmap's own space

 - Uses ratelimit to avoid too many error prints on I/O error path

* tag 'exfat-for-6.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat:
  exfat: Add support for FS_IOC_{GET,SET}FSLABEL
  exfat: combine iocharset and utf8 option setup
  exfat: support modifying mount options via remount
  exfat: optimize allocation bitmap loading time
  exfat: Remove unnecessary parentheses
  exfat: drop redundant conversion to bool
  exfat: validate cluster allocation bits of the allocation bitmap
  exfat: limit log print for IO error
</content>
</entry>
</feed>
