<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/fs/overlayfs/readdir.c, branch v6.12.91</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.12.91</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.12.91'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-03-04T12:20:32+00:00</updated>
<entry>
<title>ovl: Fix uninit-value in ovl_fill_real</title>
<updated>2026-03-04T12:20:32+00:00</updated>
<author>
<name>Qing Wang</name>
<email>wangqing7171@gmail.com</email>
</author>
<published>2026-01-28T13:24:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=721f679d4eb2b243cf72f775197f0a185a98eb0a'/>
<id>urn:sha1:721f679d4eb2b243cf72f775197f0a185a98eb0a</id>
<content type='text'>
[ Upstream commit 1992330d90dd766fcf1730fd7bf2d6af65370ac4 ]

Syzbot reported a KMSAN uninit-value issue in ovl_fill_real.

This iusse's call chain is:
__do_sys_getdents64()
    -&gt; iterate_dir()
        ...
            -&gt; ext4_readdir()
                -&gt; fscrypt_fname_alloc_buffer() // alloc
                -&gt; fscrypt_fname_disk_to_usr // write without tail '\0'
                -&gt; dir_emit()
                    -&gt; ovl_fill_real() // read by strcmp()

The string is used to store the decrypted directory entry name for an
encrypted inode. As shown in the call chain, fscrypt_fname_disk_to_usr()
write it without null-terminate. However, ovl_fill_real() uses strcmp() to
compare the name against "..", which assumes a null-terminated string and
may trigger a KMSAN uninit-value warning when the buffer tail contains
uninit data.

Reported-by: syzbot+d130f98b2c265fae5297@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=d130f98b2c265fae5297
Fixes: 4edb83bb1041 ("ovl: constant d_ino for non-merge dirs")
Signed-off-by: Qing Wang &lt;wangqing7171@gmail.com&gt;
Signed-off-by: Amir Goldstein &lt;amir73il@gmail.com&gt;
Link: https://patch.msgid.link/20260128132406.23768-2-amir73il@gmail.com
Acked-by: Miklos Szeredi &lt;mszeredi@redhat.com&gt;
Reviewed-by: Eric Biggers &lt;ebiggers@kernel.org&gt;
Signed-off-by: Christian Brauner &lt;brauner@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ovl: mark xwhiteouts directory with overlay.opaque='x'</title>
<updated>2024-01-23T10:39:48+00:00</updated>
<author>
<name>Amir Goldstein</name>
<email>amir73il@gmail.com</email>
</author>
<published>2024-01-20T10:18:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=420332b94119cdc7db4477cc88484691cb92ae71'/>
<id>urn:sha1:420332b94119cdc7db4477cc88484691cb92ae71</id>
<content type='text'>
An opaque directory cannot have xwhiteouts, so instead of marking an
xwhiteouts directory with a new xattr, overload overlay.opaque xattr
for marking both opaque dir ('y') and xwhiteouts dir ('x').

This is more efficient as the overlay.opaque xattr is checked during
lookup of directory anyway.

This also prevents unnecessary checking the xattr when reading a
directory without xwhiteouts, i.e. most of the time.

Note that the xwhiteouts marker is not checked on the upper layer and
on the last layer in lowerstack, where xwhiteouts are not expected.

Fixes: bc8df7a3dc03 ("ovl: Add an alternative type of whiteout")
Cc: &lt;stable@vger.kernel.org&gt; # v6.7
Reviewed-by: Alexander Larsson &lt;alexl@redhat.com&gt;
Tested-by: Alexander Larsson &lt;alexl@redhat.com&gt;
Signed-off-by: Amir Goldstein &lt;amir73il@gmail.com&gt;
</content>
</entry>
<entry>
<title>ovl: remove redundant ofs-&gt;indexdir member</title>
<updated>2023-11-20T07:49:09+00:00</updated>
<author>
<name>Amir Goldstein</name>
<email>amir73il@gmail.com</email>
</author>
<published>2023-11-19T18:55:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=02d70090e0e020eff440dbe51e93fe2fc94d9835'/>
<id>urn:sha1:02d70090e0e020eff440dbe51e93fe2fc94d9835</id>
<content type='text'>
When the index feature is disabled, ofs-&gt;indexdir is NULL.
When the index feature is enabled, ofs-&gt;indexdir has the same value as
ofs-&gt;workdir and takes an extra reference.

This makes the code harder to understand when it is not always clear
that ofs-&gt;indexdir in one function is the same dentry as ofs-&gt;workdir
in another function.

Remove this redundancy, by referencing ofs-&gt;workdir directly in index
helpers and by using the ovl_indexdir() accessor in generic code.

Signed-off-by: Amir Goldstein &lt;amir73il@gmail.com&gt;
</content>
</entry>
<entry>
<title>ovl: Add an alternative type of whiteout</title>
<updated>2023-10-30T22:12:59+00:00</updated>
<author>
<name>Alexander Larsson</name>
<email>alexl@redhat.com</email>
</author>
<published>2023-08-23T14:33:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bc8df7a3dc035903426a17ea3027f55817de13a8'/>
<id>urn:sha1:bc8df7a3dc035903426a17ea3027f55817de13a8</id>
<content type='text'>
An xattr whiteout (called "xwhiteout" in the code) is a reguar file of
zero size with the "overlay.whiteout" xattr set. A file like this in a
directory with the "overlay.whiteouts" xattrs set will be treated the
same way as a regular whiteout.

The "overlay.whiteouts" directory xattr is used in order to
efficiently handle overlay checks in readdir(), as we only need to
checks xattrs in affected directories.

The advantage of this kind of whiteout is that they can be escaped
using the standard overlay xattr escaping mechanism. So, a file with a
"overlay.overlay.whiteout" xattr would be unescaped to
"overlay.whiteout", which could then be consumed by another overlayfs
as a whiteout.

Overlayfs itself doesn't create whiteouts like this, but a userspace
mechanism could use this alternative mechanism to convert images that
may contain whiteouts to be used with overlayfs.

To work as a whiteout for both regular overlayfs mounts as well as
userxattr mounts both the "user.overlay.whiteout*" and the
"trusted.overlay.whiteout*" xattrs will need to be created.

Signed-off-by: Alexander Larsson &lt;alexl@redhat.com&gt;
Reviewed-by: Amir Goldstein &lt;amir73il@gmail.com&gt;
Signed-off-by: Amir Goldstein &lt;amir73il@gmail.com&gt;
</content>
</entry>
<entry>
<title>vfs: get rid of old '-&gt;iterate' directory operation</title>
<updated>2023-08-06T13:08:35+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2023-08-05T19:25:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3e3271549670783be20e233a2b78a87a0b04c715'/>
<id>urn:sha1:3e3271549670783be20e233a2b78a87a0b04c715</id>
<content type='text'>
All users now just use '-&gt;iterate_shared()', which only takes the
directory inode lock for reading.

Filesystems that never got convered to shared mode now instead use a
wrapper that drops the lock, re-takes it in write mode, calls the old
function, and then downgrades the lock back to read mode.

This way the VFS layer and other callers no longer need to care about
filesystems that never got converted to the modern era.

The filesystems that use the new wrapper are ceph, coda, exfat, jfs,
ntfs, ocfs2, overlayfs, and vboxsf.

Honestly, several of them look like they really could just iterate their
directories in shared mode and skip the wrapper entirely, but the point
of this change is to not change semantics or fix filesystems that
haven't been fixed in the last 7+ years, but to finally get rid of the
dual iterators.

Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Christian Brauner &lt;brauner@kernel.org&gt;
</content>
</entry>
<entry>
<title>ovl: pass ovl_fs to xino helpers</title>
<updated>2023-06-19T11:02:00+00:00</updated>
<author>
<name>Amir Goldstein</name>
<email>amir73il@gmail.com</email>
</author>
<published>2023-05-25T05:40:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=dcb399de1e404f48b07ebdcc434ec600568c90eb'/>
<id>urn:sha1:dcb399de1e404f48b07ebdcc434ec600568c90eb</id>
<content type='text'>
Internal ovl methods should use ovl_fs and not sb as much as
possible.

Use a constant_table to translate from enum xino mode to string
in preperation for new mount api option parsing.

Signed-off-by: Amir Goldstein &lt;amir73il@gmail.com&gt;
</content>
</entry>
<entry>
<title>fs: port -&gt;permission() to pass mnt_idmap</title>
<updated>2023-01-19T08:24:28+00:00</updated>
<author>
<name>Christian Brauner</name>
<email>brauner@kernel.org</email>
</author>
<published>2023-01-13T11:49:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4609e1f18e19c3b302e1eb4858334bca1532f780'/>
<id>urn:sha1:4609e1f18e19c3b302e1eb4858334bca1532f780</id>
<content type='text'>
Convert to struct mnt_idmap.

Last cycle we merged the necessary infrastructure in
256c8aed2b42 ("fs: introduce dedicated idmap type for mounts").
This is just the conversion to struct mnt_idmap.

Currently we still pass around the plain namespace that was attached to a
mount. This is in general pretty convenient but it makes it easy to
conflate namespaces that are relevant on the filesystem with namespaces
that are relevent on the mount level. Especially for non-vfs developers
without detailed knowledge in this area this can be a potential source for
bugs.

Once the conversion to struct mnt_idmap is done all helpers down to the
really low-level helpers will take a struct mnt_idmap argument instead of
two namespace arguments. This way it becomes impossible to conflate the two
eliminating the possibility of any bugs. All of the vfs and all filesystems
only operate on struct mnt_idmap.

Acked-by: Dave Chinner &lt;dchinner@redhat.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Christian Brauner (Microsoft) &lt;brauner@kernel.org&gt;
</content>
</entry>
<entry>
<title>ovl: use inode instead of dentry where possible</title>
<updated>2022-12-08T09:49:46+00:00</updated>
<author>
<name>Miklos Szeredi</name>
<email>mszeredi@redhat.com</email>
</author>
<published>2022-10-07T15:35:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1fa9c5c5eddef0505b353031b7605c97e4257e62'/>
<id>urn:sha1:1fa9c5c5eddef0505b353031b7605c97e4257e62</id>
<content type='text'>
Passing dentry to some helpers is unnecessary.  Simplify these cases.

Signed-off-by: Miklos Szeredi &lt;mszeredi@redhat.com&gt;
</content>
</entry>
<entry>
<title>ovl: use plain list filler in indexdir and workdir cleanup</title>
<updated>2022-12-08T09:49:46+00:00</updated>
<author>
<name>Amir Goldstein</name>
<email>amir73il@gmail.com</email>
</author>
<published>2022-10-04T10:34:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=af4dcb6d78b2b05a0431dfd3f67713bba8dc0900'/>
<id>urn:sha1:af4dcb6d78b2b05a0431dfd3f67713bba8dc0900</id>
<content type='text'>
Those two cleanup routines are using the helper ovl_dir_read() with the
merge dir filler, which populates an rb tree, that is never used.

The index dir entry names all have a long (42 bytes) constant prefix, so it
is not surprising that perf top has demostrated high CPU usage by rb tree
population during cleanup of a large index dir:

      - 9.53% ovl_fill_merge
         - 78.41% ovl_cache_entry_find_link.constprop.27
            + 72.11% strncmp

Use the plain list filler that does not populate the unneeded rb tree.

Signed-off-by: Amir Goldstein &lt;amir73il@gmail.com&gt;
Signed-off-by: Miklos Szeredi &lt;mszeredi@redhat.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'pull-path' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs</title>
<updated>2022-10-07T00:31:02+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2022-10-07T00:31:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4c0ed7d8d6e3dc013c4599a837de84794baa5b62'/>
<id>urn:sha1:4c0ed7d8d6e3dc013c4599a837de84794baa5b62</id>
<content type='text'>
Pull vfs constification updates from Al Viro:
 "whack-a-mole: constifying struct path *"

* tag 'pull-path' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  ecryptfs: constify path
  spufs: constify path
  nd_jump_link(): constify path
  audit_init_parent(): constify path
  __io_setxattr(): constify path
  do_proc_readlink(): constify path
  overlayfs: constify path
  fs/notify: constify path
  may_linkat(): constify path
  do_sys_name_to_handle(): constify path
  -&gt;getprocattr(): attribute name is const char *, TYVM...
</content>
</entry>
</feed>
