<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/fs/erofs, branch v7.0.10</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v7.0.10</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v7.0.10'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-05-23T11:09:16+00:00</updated>
<entry>
<title>erofs: unify lcn as u64 for 32-bit platforms</title>
<updated>2026-05-23T11:09:16+00:00</updated>
<author>
<name>Gao Xiang</name>
<email>hsiangkao@linux.alibaba.com</email>
</author>
<published>2026-04-20T10:11:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=582b0bf201157632cb5474c885989a6ebda46521'/>
<id>urn:sha1:582b0bf201157632cb5474c885989a6ebda46521</id>
<content type='text'>
[ Upstream commit 2d8c7edcb661812249469f4a5b62e9339118846f ]

As sashiko reported [1], `lcn` was typed as `unsigned long` (or
`unsigned int` sometimes), which is only 32 bits wide on 32-bit
platforms, which causes `(lcn &lt;&lt; lclusterbits)` to be truncated
at 4 GiB.

In order to consolidate the logic, just use `u64` consistently
around the codebase.

[1] https://sashiko.dev/r/20260420034612.1899973-1-hsiangkao%40linux.alibaba.com

Fixes: 152a333a5895 ("staging: erofs: add compacted compression indexes support")
Signed-off-by: Gao Xiang &lt;hsiangkao@linux.alibaba.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>erofs: handle 48-bit blocks/uniaddr for extra devices</title>
<updated>2026-05-23T11:08:27+00:00</updated>
<author>
<name>Zhan Xusheng</name>
<email>zhanxusheng1024@gmail.com</email>
</author>
<published>2026-04-03T06:36:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ab2f07bf4520e604963b16f316c5e5ab3e7ddb24'/>
<id>urn:sha1:ab2f07bf4520e604963b16f316c5e5ab3e7ddb24</id>
<content type='text'>
[ Upstream commit 63c2f06198ca7513433f1c92f2c654869d72417e ]

erofs_init_device() only reads blocks_lo and uniaddr_lo from the
on-disk device slot, ignoring blocks_hi and uniaddr_hi that were
introduced alongside the 48-bit block addressing feature.

For the primary device (dif0), erofs_read_superblock() already handles
this correctly by combining blocks_lo with blocks_hi when 48-bit
layout is enabled.  But the same logic was not applied to extra
devices.

With a 48-bit EROFS image using extra devices whose uniaddr or blocks
exceed 32-bit range, the truncated values cause erofs_map_dev() to
compute wrong physical addresses, leading to silent data corruption.

Fix this by reading blocks_hi and uniaddr_hi in erofs_init_device()
when 48-bit layout is enabled, consistent with the primary device
handling.  Also fix the erofs_deviceslot on-disk definition where
blocks_hi was incorrectly declared as __le32 instead of __le16.

Fixes: 61ba89b57905 ("erofs: add 48-bit block addressing on-disk support")
Suggested-by: Gao Xiang &lt;hsiangkao@linux.alibaba.com&gt;
Signed-off-by: Zhan Xusheng &lt;zhanxusheng@xiaomi.com&gt;
Reviewed-by: Gao Xiang &lt;hsiangkao@linux.alibaba.com&gt;
Signed-off-by: Gao Xiang &lt;hsiangkao@linux.alibaba.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>erofs: include the trailing NUL in FS_IOC_GETFSLABEL</title>
<updated>2026-05-23T11:08:26+00:00</updated>
<author>
<name>Zhan Xusheng</name>
<email>zhanxusheng1024@gmail.com</email>
</author>
<published>2026-04-01T06:13:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a43d77bac0b76105e90a72b281d1b0fa5111317c'/>
<id>urn:sha1:a43d77bac0b76105e90a72b281d1b0fa5111317c</id>
<content type='text'>
[ Upstream commit d6250d49da4d8f11afc0d8991c84e0307949f92e ]

erofs_ioctl_get_volume_label() passes strlen(sbi-&gt;volume_name) as
the length to copy_to_user(), which copies the label string without
the trailing NUL byte.  Since FS_IOC_GETFSLABEL callers expect a
NUL-terminated string in the FSLABEL_MAX-sized buffer and may not
pre-zero the buffer, this can cause userspace to read past the label
into uninitialised stack memory.

Fix this by using strlen() + 1 to include the NUL terminator,
consistent with how ext4 and xfs implement FS_IOC_GETFSLABEL.

Signed-off-by: Zhan Xusheng &lt;zhanxusheng@xiaomi.com&gt;
Fixes: 1cf12c717741 ("erofs: Add support for FS_IOC_GETFSLABEL")
Reviewed-by: Gao Xiang &lt;hsiangkao@linux.alibaba.com&gt;
Reviewed-by: Chunhai Guo &lt;guochunhai@vivo.com&gt;
Signed-off-by: Gao Xiang &lt;hsiangkao@linux.alibaba.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>erofs: fix unsigned underflow in z_erofs_lz4_handle_overlap()</title>
<updated>2026-05-07T04:14:13+00:00</updated>
<author>
<name>Junrui Luo</name>
<email>moonafterrain@outlook.com</email>
</author>
<published>2026-04-09T13:59:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bbbbb3f0d7864238a8da2a94cd6ec013fee06a2e'/>
<id>urn:sha1:bbbbb3f0d7864238a8da2a94cd6ec013fee06a2e</id>
<content type='text'>
commit 21e161de2dc660b1bb70ef5b156ab8e6e1cca3ab upstream.

Some crafted images can have illegal (!partial_decoding &amp;&amp;
m_llen &lt; m_plen) extents, and the LZ4 inplace decompression path
can be wrongly hit, but it cannot handle (outpages &lt; inpages)
properly: "outpages - inpages" wraps to a large value and
the subsequent rq-&gt;out[] access reads past the decompressed_pages
array.

However, such crafted cases can correctly result in a corruption
report in the normal LZ4 non-inplace path.

Let's add an additional check to fix this for backporting.

Reproducible image (base64-encoded gzipped blob):

H4sIAJGR12kCA+3SPUoDQRgG4MkmkkZk8QRbRFIIi9hbpEjrHQI5ghfwCN5BLCzTGtLbBI+g
dilSJo1CnIm7GEXFxhT6PDDwfrs73/ywIQD/1ePD4r7Ou6ETsrq4mu7XcWfj++Pb58nJU/9i
PNtbjhan04/9GtX4qVYc814WDqt6FaX5s+ZwXXeq52lndT6IuVvlblytLMvh4Gzwaf90nsvz
2DF/21+20T/ldgp5s1jXRaN4t/8izsy/OUB6e/Qa79r+JwAAAAAAAL52vQVuGQAAAP6+my1w
ywAAAAAAAADwu14ATsEYtgBQAAA=

$ mount -t erofs -o cache_strategy=disabled foo.erofs /mnt
$ dd if=/mnt/data of=/dev/null bs=4096 count=1

Fixes: 598162d05080 ("erofs: support decompress big pcluster for lz4 backend")
Reported-by: Yuhao Jiang &lt;danisjiang@gmail.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Junrui Luo &lt;moonafterrain@outlook.com&gt;
Reviewed-by: Gao Xiang &lt;hsiangkao@linux.alibaba.com&gt;
Signed-off-by: Gao Xiang &lt;hsiangkao@linux.alibaba.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>lsm: add backing_file LSM hooks</title>
<updated>2026-05-07T04:14:01+00:00</updated>
<author>
<name>Paul Moore</name>
<email>paul@paul-moore.com</email>
</author>
<published>2025-12-19T18:18:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=27e795afba0018b0ea9460dbad4bd706d1ba5ee0'/>
<id>urn:sha1:27e795afba0018b0ea9460dbad4bd706d1ba5ee0</id>
<content type='text'>
commit 6af36aeb147a06dea47c49859cd6ca5659aeb987 upstream.

Stacked filesystems such as overlayfs do not currently provide the
necessary mechanisms for LSMs to properly enforce access controls on the
mmap() and mprotect() operations.  In order to resolve this gap, a LSM
security blob is being added to the backing_file struct and the following
new LSM hooks are being created:

 security_backing_file_alloc()
 security_backing_file_free()
 security_mmap_backing_file()

The first two hooks are to manage the lifecycle of the LSM security blob
in the backing_file struct, while the third provides a new mmap() access
control point for the underlying backing file.  It is also expected that
LSMs will likely want to update their security_file_mprotect() callback
to address issues with their mprotect() controls, but that does not
require a change to the security_file_mprotect() LSM hook.

There are a three other small changes to support these new LSM hooks:
* Pass the user file associated with a backing file down to
alloc_empty_backing_file() so it can be included in the
security_backing_file_alloc() hook.
* Add getter and setter functions for the backing_file struct LSM blob
as the backing_file struct remains private to fs/file_table.c.
* Constify the file struct field in the LSM common_audit_data struct to
better support LSMs that need to pass a const file struct pointer into
the common LSM audit code.

Thanks to Arnd Bergmann for identifying the missing EXPORT_SYMBOL_GPL()
and supplying a fixup.

Cc: stable@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-unionfs@vger.kernel.org
Cc: linux-erofs@lists.ozlabs.org
Reviewed-by: Amir Goldstein &lt;amir73il@gmail.com&gt;
Reviewed-by: Serge Hallyn &lt;serge@hallyn.com&gt;
Reviewed-by: Christian Brauner &lt;brauner@kernel.org&gt;
Signed-off-by: Paul Moore &lt;paul@paul-moore.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>erofs: fix the out-of-bounds nameoff handling for trailing dirents</title>
<updated>2026-05-07T04:13:49+00:00</updated>
<author>
<name>Gao Xiang</name>
<email>hsiangkao@linux.alibaba.com</email>
</author>
<published>2026-04-21T07:59:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1d55445226c75ddd4e78b09b3e7d99109b28c366'/>
<id>urn:sha1:1d55445226c75ddd4e78b09b3e7d99109b28c366</id>
<content type='text'>
commit d18a3b5d337fa412a38e776e6b4b857a58836575 upstream.

Currently we already have boundary-checks for nameoffs, but the trailing
dirents are special since the namelens are calculated with strnlen()
with unchecked nameoffs.

If a crafted EROFS has a trailing dirent with nameoff &gt;= maxsize,
maxsize - nameoff can underflow, causing strnlen() to read past the
directory block.

nameoff0 should also be verified to be a multiple of
`sizeof(struct erofs_dirent)` as well [1].

[1] https://sashiko.dev/#/patchset/20260416063511.3173774-1-hsiangkao%40linux.alibaba.com

Fixes: 3aa8ec716e52 ("staging: erofs: add directory operations")
Fixes: 33bac912840f ("staging: erofs: keep corrupted fs from crashing kernel in erofs_readdir()")
Reported-by: Yuhao Jiang &lt;danisjiang@gmail.com&gt;
Reported-by: Junrui Luo &lt;moonafterrain@outlook.com&gt;
Closes: https://lore.kernel.org/r/A0FD7E0F-7558-49B0-8BC8-EB1ECDB2479A@outlook.com
Cc: stable@vger.kernel.org
Signed-off-by: Gao Xiang &lt;hsiangkao@linux.alibaba.com&gt;
Reviewed-by: Chao Yu &lt;chao@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>erofs: fix .fadvise() for page cache sharing</title>
<updated>2026-03-25T02:40:02+00:00</updated>
<author>
<name>Gao Xiang</name>
<email>hsiangkao@linux.alibaba.com</email>
</author>
<published>2026-03-24T15:54:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2f0407ed923b7eb363424033fc12fe253da139c4'/>
<id>urn:sha1:2f0407ed923b7eb363424033fc12fe253da139c4</id>
<content type='text'>
Currently, .fadvise() doesn't work well if page cache sharing is on
since shared inodes belong to a pseudo fs generated with init_pseudo(),
and sb-&gt;s_bdi is the default one &amp;noop_backing_dev_info.

Then, generic_fadvise() will just behave as a no-op if sb-&gt;s_bdi is
&amp;noop_backing_dev_info, but as the bdev fs (the bdev fs changes
inode_to_bdi() instead), it's actually NOT a pure memfs.

Let's generate a real bdi for erofs_ishare_mnt instead.

Fixes: d86d7817c042 ("erofs: implement .fadvise for page cache share")
Reviewed-by: Hongbo Li &lt;lihongbo22@huawei.com&gt;
Signed-off-by: Gao Xiang &lt;hsiangkao@linux.alibaba.com&gt;
</content>
</entry>
<entry>
<title>erofs: update the Kconfig description</title>
<updated>2026-03-24T16:04:41+00:00</updated>
<author>
<name>Gao Xiang</name>
<email>hsiangkao@linux.alibaba.com</email>
</author>
<published>2026-03-23T09:48:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=938c418422c4b08523ae39aebbd828428dcfefd2'/>
<id>urn:sha1:938c418422c4b08523ae39aebbd828428dcfefd2</id>
<content type='text'>
Refine the description to better highlight its features and use cases.

In addition, add instructions for building it as a module and clarify
the compression option.

Reviewed-by: Chao Yu &lt;chao@kernel.org&gt;
Signed-off-by: Gao Xiang &lt;hsiangkao@linux.alibaba.com&gt;
</content>
</entry>
<entry>
<title>erofs: add GFP_NOIO in the bio completion if needed</title>
<updated>2026-03-18T16:24:21+00:00</updated>
<author>
<name>Jiucheng Xu</name>
<email>jiucheng.xu@amlogic.com</email>
</author>
<published>2026-03-11T09:11:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c23df30915f83e7257c8625b690a1cece94142a0'/>
<id>urn:sha1:c23df30915f83e7257c8625b690a1cece94142a0</id>
<content type='text'>
The bio completion path in the process context (e.g. dm-verity)
will directly call into decompression rather than trigger another
workqueue context for minimal scheduling latencies, which can
then call vm_map_ram() with GFP_KERNEL.

Due to insufficient memory, vm_map_ram() may generate memory
swapping I/O, which can cause submit_bio_wait to deadlock
in some scenarios.

Trimmed down the call stack, as follows:

f2fs_submit_read_io
  submit_bio                      //bio_list is initialized.
    mmc_blk_mq_recovery
      z_erofs_endio
        vm_map_ram
          __pte_alloc_kernel
            __alloc_pages_direct_reclaim
              shrink_folio_list
                __swap_writepage
                  submit_bio_wait  //bio_list is non-NULL, hang!!!

Use memalloc_noio_{save,restore}() to wrap up this path.

Reviewed-by: Gao Xiang &lt;hsiangkao@linux.alibaba.com&gt;
Signed-off-by: Jiucheng Xu &lt;jiucheng.xu@amlogic.com&gt;
Reviewed-by: Chao Yu &lt;chao@kernel.org&gt;
Signed-off-by: Gao Xiang &lt;hsiangkao@linux.alibaba.com&gt;
</content>
</entry>
<entry>
<title>erofs: set fileio bio failed in short read case</title>
<updated>2026-03-17T02:27:31+00:00</updated>
<author>
<name>Sheng Yong</name>
<email>shengyong1@xiaomi.com</email>
</author>
<published>2026-02-27T02:30:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=eade54040384f54b7fb330e4b0975c5734850b3c'/>
<id>urn:sha1:eade54040384f54b7fb330e4b0975c5734850b3c</id>
<content type='text'>
For file-backed mount, IO requests are handled by vfs_iocb_iter_read().
However, it can be interrupted by SIGKILL, returning the number of
bytes actually copied. Unused folios in bio are unexpectedly marked
as uptodate.

  vfs_read
    filemap_read
      filemap_get_pages
        filemap_readahead
          erofs_fileio_readahead
            erofs_fileio_rq_submit
              vfs_iocb_iter_read
                filemap_read
                  filemap_get_pages  &lt;= detect signal
              erofs_fileio_ki_complete  &lt;= set all folios uptodate

This patch addresses this by setting short read bio with an error
directly.

Fixes: bc804a8d7e86 ("erofs: handle end of filesystem properly for file-backed mounts")
Reported-by: chenguanyou &lt;chenguanyou@xiaomi.com&gt;
Signed-off-by: Yunlei He &lt;heyunlei@xiaomi.com&gt;
Signed-off-by: Sheng Yong &lt;shengyong1@xiaomi.com&gt;
Reviewed-by: Gao Xiang &lt;hsiangkao@linux.alibaba.com&gt;
Reviewed-by: Chao Yu &lt;chao@kernel.org&gt;
Signed-off-by: Gao Xiang &lt;hsiangkao@linux.alibaba.com&gt;
</content>
</entry>
</feed>
