<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/fs/smb/client/file.c, branch linux-rolling-stable</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-rolling-stable</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-rolling-stable'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2026-03-19T15:15:28Z</updated>
<entry>
<title>smb: client: fix atomic open with O_DIRECT &amp; O_SYNC</title>
<updated>2026-03-19T15:15:28Z</updated>
<author>
<name>Paulo Alcantara</name>
<email>pc@manguebit.org</email>
</author>
<published>2026-03-07T21:20:16Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=2558bef1a8eba050a46ffa89d30a69c0d8cf3286'/>
<id>urn:sha1:2558bef1a8eba050a46ffa89d30a69c0d8cf3286</id>
<content type='text'>
commit 4a7d2729dc99437dbb880a64c47828c0d191b308 upstream.

When user application requests O_DIRECT|O_SYNC along with O_CREAT on
open(2), CREATE_NO_BUFFER and CREATE_WRITE_THROUGH bits were missed in
CREATE request when performing an atomic open, thus leading to
potentially data integrity issues.

Fix this by setting those missing bits in CREATE request when
O_DIRECT|O_SYNC has been specified in cifs_do_create().

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Paulo Alcantara (Red Hat) &lt;pc@manguebit.org&gt;
Reviewed-by: David Howells &lt;dhowells@redhat.com&gt;
Acked-by: Henrique Carvalho &lt;henrique.carvalho@suse.com&gt;
Cc: Tom Talpey &lt;tom@talpey.com&gt;
Cc: linux-cifs@vger.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>cifs: Add a tracepoint to log EIO errors</title>
<updated>2025-12-05T23:11:43Z</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2025-10-24T08:25:31Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f80ac7eda1cf5205aaa2b676827ae1e312a5a894'/>
<id>urn:sha1:f80ac7eda1cf5205aaa2b676827ae1e312a5a894</id>
<content type='text'>
Add a tracepoint to log EIO errors and give it the capacity to convey up to
two integers of information.  This is then wrapped with three functions:

 int smb_EIO(enum smb_eio_trace trace)
 int smb_EIO1(enum smb_eio_trace trace, unsigned long info)
 int smb_EIO2(enum smb_eio_trace trace, unsigned long info,
	      unsigned long info2)

depending on how many bits of info are desired to be logged with any
particular trace.  The functions all return -EIO and can be used in place
of -EIO.

The trace argument is an enum value that gets translated to a string when
the trace is printed.

This makes is easier to log EIO instances when the client is under high
load than turning on a printk wrapper such as cifs_dbg().  Granted, EIO
could have its own separate EIO printing since EIO shouldn't happen.

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Reviewed-by: Paulo Alcantara (Red Hat) &lt;pc@manguebit.org&gt;
cc: linux-cifs@vger.kernel.org
cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</content>
</entry>
<entry>
<title>fs: inline current_umask() and move it to fs_struct.h</title>
<updated>2025-11-05T21:51:23Z</updated>
<author>
<name>Mateusz Guzik</name>
<email>mjguzik@gmail.com</email>
</author>
<published>2025-11-04T17:04:48Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=5b8ed52866e3d19e02860c7cf1d6bbbd70b619e9'/>
<id>urn:sha1:5b8ed52866e3d19e02860c7cf1d6bbbd70b619e9</id>
<content type='text'>
There is no good reason to have this as a func call, other than avoiding
the churn of adding fs_struct.h as needed.

Signed-off-by: Mateusz Guzik &lt;mjguzik@gmail.com&gt;
Link: https://patch.msgid.link/20251104170448.630414-1-mjguzik@gmail.com
Signed-off-by: Christian Brauner &lt;brauner@kernel.org&gt;
</content>
</entry>
<entry>
<title>smb: client: remove redudant assignment in cifs_strict_fsync()</title>
<updated>2025-10-09T16:16:25Z</updated>
<author>
<name>Paulo Alcantara</name>
<email>pc@manguebit.org</email>
</author>
<published>2025-10-09T15:41:16Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=be3898a395f830ef7eaff70df557f57315c61c81'/>
<id>urn:sha1:be3898a395f830ef7eaff70df557f57315c61c81</id>
<content type='text'>
Remove redudant assignment of @rc as it will be overwritten by the
following cifs_file_flush() call.

Reported-by: Steve French &lt;stfrench@microsoft.com&gt;
Addresses-Coverity: 1665925
Fixes: 210627b0aca9 ("smb: client: fix missing timestamp updates with O_TRUNC")
Signed-off-by: Paulo Alcantara (Red Hat) &lt;pc@manguebit.org&gt;
Cc: linux-cifs@vger.kernel.org
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</content>
</entry>
<entry>
<title>smb: client: fix missing timestamp updates with O_TRUNC</title>
<updated>2025-10-09T15:42:14Z</updated>
<author>
<name>Paulo Alcantara</name>
<email>pc@manguebit.org</email>
</author>
<published>2025-10-07T19:23:22Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=110fee6b9bb58a5c50047fc2594d415f741b591e'/>
<id>urn:sha1:110fee6b9bb58a5c50047fc2594d415f741b591e</id>
<content type='text'>
Don't call -&gt;set_file_info() on open handle to prevent the server from
stopping [cm]time updates automatically as per MS-FSA 2.1.4.17.

Fix this by checking for ATTR_OPEN bit earlier in cifs_setattr() to
prevent -&gt;set_file_info() from being called when opening a file with
O_TRUNC.  Do the truncation in -&gt;open() instead.

This also saves two roundtrips when opening a file with O_TRUNC and
there are currently no open handles to be reused.

Before patch:

$ mount.cifs //srv/share /mnt -o ...
$ cd /mnt
$ exec 3&gt;foo; stat -c 'old: %z %y' foo; sleep 2; echo test &gt;&amp;3; exec 3&gt;&amp;-; sleep 2; stat -c 'new: %z %y' foo
old: 2025-10-03 13:26:23.151030500 -0300 2025-10-03 13:26:23.151030500 -0300
new: 2025-10-03 13:26:23.151030500 -0300 2025-10-03 13:26:23.151030500 -0300

After patch:

$ mount.cifs //srv/share /mnt -o ...
$ cd /mnt
$ exec 3&gt;foo; stat -c 'old: %z %y' foo; sleep 2; echo test &gt;&amp;3; exec 3&gt;&amp;-; sleep 2; stat -c 'new: %z %y' foo
$ exec 3&gt;foo; stat -c 'old: %z %y' foo; sleep 2; echo test &gt;&amp;3; exec 3&gt;&amp;-; sleep 2; stat -c 'new: %z %y' foo
old: 2025-10-03 13:28:13.911933800 -0300 2025-10-03 13:28:13.911933800 -0300
new: 2025-10-03 13:28:26.647492700 -0300 2025-10-03 13:28:26.647492700 -0300

Reported-by: Frank Sorenson &lt;sorenson@redhat.com&gt;
Signed-off-by: Paulo Alcantara (Red Hat) &lt;pc@manguebit.org&gt;
Reviewed-by: David Howells &lt;dhowells@redhat.com&gt;
Cc: linux-cifs@vger.kernel.org
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</content>
</entry>
<entry>
<title>smb: client: make use of smbdirect_socket_parameters.max_frmr_depth</title>
<updated>2025-09-28T23:29:50Z</updated>
<author>
<name>Stefan Metzmacher</name>
<email>metze@samba.org</email>
</author>
<published>2025-08-21T22:32:34Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=9a52e3b0d63fc5eaefee3707136fa3c5258ae39e'/>
<id>urn:sha1:9a52e3b0d63fc5eaefee3707136fa3c5258ae39e</id>
<content type='text'>
This make it easier to have common code later.

Cc: Steve French &lt;smfrench@gmail.com&gt;
Cc: Tom Talpey &lt;tom@talpey.com&gt;
Cc: Long Li &lt;longli@microsoft.com&gt;
Cc: linux-cifs@vger.kernel.org
Cc: samba-technical@lists.samba.org
Acked-by: Namjae Jeon &lt;linkinjeon@kernel.org&gt;
Signed-off-by: Stefan Metzmacher &lt;metze@samba.org&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</content>
</entry>
<entry>
<title>smb: client: fix data loss due to broken rename(2)</title>
<updated>2025-09-09T23:39:58Z</updated>
<author>
<name>Paulo Alcantara</name>
<email>pc@manguebit.org</email>
</author>
<published>2025-09-08T00:24:06Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=c5ea3065586d790ea5193a679b85585173d59866'/>
<id>urn:sha1:c5ea3065586d790ea5193a679b85585173d59866</id>
<content type='text'>
Rename of open files in SMB2+ has been broken for a very long time,
resulting in data loss as the CIFS client would fail the rename(2)
call with -ENOENT and then removing the target file.

Fix this by implementing -&gt;rename_pending_delete() for SMB2+, which
will rename busy files to random filenames (e.g. silly rename) during
unlink(2) or rename(2), and then marking them to delete-on-close.

Besides, introduce a FIND_WR_NO_PENDING_DELETE flag to prevent open(2)
from reusing open handles that had been marked as delete pending.
Handle it in cifs_get_readable_path() as well.

Reported-by: Jean-Baptiste Denis &lt;jbdenis@pasteur.fr&gt;
Closes: https://marc.info/?i=16aeb380-30d4-4551-9134-4e7d1dc833c0@pasteur.fr
Reviewed-by: David Howells &lt;dhowells@redhat.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Paulo Alcantara (Red Hat) &lt;pc@manguebit.org&gt;
Cc: Frank Sorenson &lt;sorenson@redhat.com&gt;
Cc: Olga Kornievskaia &lt;okorniev@redhat.com&gt;
Cc: Benjamin Coddington &lt;bcodding@redhat.com&gt;
Cc: Scott Mayhew &lt;smayhew@redhat.com&gt;
Cc: linux-cifs@vger.kernel.org
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'vfs-6.17-rc1.mmap_prepare' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs</title>
<updated>2025-07-28T20:43:25Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2025-07-28T20:43:25Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=7031769e102b768b3fa0c4c726faf532cb31e973'/>
<id>urn:sha1:7031769e102b768b3fa0c4c726faf532cb31e973</id>
<content type='text'>
Pull mmap_prepare updates from Christian Brauner:
 "Last cycle we introduce f_op-&gt;mmap_prepare() in c84bf6dd2b83 ("mm:
  introduce new .mmap_prepare() file callback").

  This is preferred to the existing f_op-&gt;mmap() hook as it does require
  a VMA to be established yet, thus allowing the mmap logic to invoke
  this hook far, far earlier, prior to inserting a VMA into the virtual
  address space, or performing any other heavy handed operations.

  This allows for much simpler unwinding on error, and for there to be a
  single attempt at merging a VMA rather than having to possibly
  reattempt a merge based on potentially altered VMA state.

  Far more importantly, it prevents inappropriate manipulation of
  incompletely initialised VMA state, which is something that has been
  the cause of bugs and complexity in the past.

  The intent is to gradually deprecate f_op-&gt;mmap, and in that vein this
  series coverts the majority of file systems to using f_op-&gt;mmap_prepare.

  Prerequisite steps are taken - firstly ensuring all checks for mmap
  capabilities use the file_has_valid_mmap_hooks() helper rather than
  directly checking for f_op-&gt;mmap (which is now not a valid check) and
  secondly updating daxdev_mapping_supported() to not require a VMA
  parameter to allow ext4 and xfs to be converted.

  Commit bb666b7c2707 ("mm: add mmap_prepare() compatibility layer for
  nested file systems") handles the nasty edge-case of nested file
  systems like overlayfs, which introduces a compatibility shim to allow
  f_op-&gt;mmap_prepare() to be invoked from an f_op-&gt;mmap() callback.

  This allows for nested filesystems to continue to function correctly
  with all file systems regardless of which callback is used. Once we
  finally convert all file systems, this shim can be removed.

  As a result, ecryptfs, fuse, and overlayfs remain unaltered so they
  can nest all other file systems.

  We additionally do not update resctl - as this requires an update to
  remap_pfn_range() (or an alternative to it) which we defer to a later
  series, equally we do not update cramfs which needs a mixed mapping
  insertion with the same issue, nor do we update procfs, hugetlbfs,
  syfs or kernfs all of which require VMAs for internal state and hooks.
  We shall return to all of these later"

* tag 'vfs-6.17-rc1.mmap_prepare' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs:
  doc: update porting, vfs documentation to describe mmap_prepare()
  fs: replace mmap hook with .mmap_prepare for simple mappings
  fs: convert most other generic_file_*mmap() users to .mmap_prepare()
  fs: convert simple use of generic_file_*_mmap() to .mmap_prepare()
  mm/filemap: introduce generic_file_*_mmap_prepare() helpers
  fs/xfs: transition from deprecated .mmap hook to .mmap_prepare
  fs/ext4: transition from deprecated .mmap hook to .mmap_prepare
  fs/dax: make it possible to check dev dax support without a VMA
  fs: consistently use can_mmap_file() helper
  mm/nommu: use file_has_valid_mmap_hooks() helper
  mm: rename call_mmap/mmap_prepare to vfs_mmap/mmap_prepare
</content>
</entry>
<entry>
<title>smb: client: fix use-after-free in cifs_oplock_break</title>
<updated>2025-07-13T22:16:29Z</updated>
<author>
<name>Wang Zhaolong</name>
<email>wangzhaolong@huaweicloud.com</email>
</author>
<published>2025-07-07T01:09:26Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=705c79101ccf9edea5a00d761491a03ced314210'/>
<id>urn:sha1:705c79101ccf9edea5a00d761491a03ced314210</id>
<content type='text'>
A race condition can occur in cifs_oplock_break() leading to a
use-after-free of the cinode structure when unmounting:

  cifs_oplock_break()
    _cifsFileInfo_put(cfile)
      cifsFileInfo_put_final()
        cifs_sb_deactive()
          [last ref, start releasing sb]
            kill_sb()
              kill_anon_super()
                generic_shutdown_super()
                  evict_inodes()
                    dispose_list()
                      evict()
                        destroy_inode()
                          call_rcu(&amp;inode-&gt;i_rcu, i_callback)
    spin_lock(&amp;cinode-&gt;open_file_lock)  &lt;- OK
                            [later] i_callback()
                              cifs_free_inode()
                                kmem_cache_free(cinode)
    spin_unlock(&amp;cinode-&gt;open_file_lock)  &lt;- UAF
    cifs_done_oplock_break(cinode)       &lt;- UAF

The issue occurs when umount has already released its reference to the
superblock. When _cifsFileInfo_put() calls cifs_sb_deactive(), this
releases the last reference, triggering the immediate cleanup of all
inodes under RCU. However, cifs_oplock_break() continues to access the
cinode after this point, resulting in use-after-free.

Fix this by holding an extra reference to the superblock during the
entire oplock break operation. This ensures that the superblock and
its inodes remain valid until the oplock break completes.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=220309
Fixes: b98749cac4a6 ("CIFS: keep FileInfo handle live during oplock break")
Reviewed-by: Paulo Alcantara (Red Hat) &lt;pc@manguebit.org&gt;
Signed-off-by: Wang Zhaolong &lt;wangzhaolong@huaweicloud.com&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</content>
</entry>
<entry>
<title>cifs: Fix prepare_write to negotiate wsize if needed</title>
<updated>2025-06-21T16:03:24Z</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2025-06-18T15:39:47Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=2c4fd3d141465ef1afc8318c95e7b916d9a8c49c'/>
<id>urn:sha1:2c4fd3d141465ef1afc8318c95e7b916d9a8c49c</id>
<content type='text'>
Fix cifs_prepare_write() to negotiate the wsize if it is unset.

Reviewed-by: Shyam Prasad N &lt;nspmangalore@gmail.com&gt;
Reviewed-by: Bharath SM &lt;bharathsm@microsoft.com&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
cc: Paulo Alcantara &lt;pc@manguebit.org&gt;
cc: netfs@lists.linux.dev
cc: linux-fsdevel@vger.kernel.org
cc: linux-cifs@vger.kernel.org
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
</content>
</entry>
</feed>
