<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://db.gcve.eu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Tue, 03 Nov 2026 16:47:04 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-98682</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-98682</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;smb: client: drain and invalidate before server-side copy/clone&lt;/p&gt;
&lt;p&gt;cifs_file_copychunk_range() and the clone (FICLONE) path of
cifs_remap_file_range() do not serialise the destination page cache
against the server-side copy the way the other server-side range
operations (smb3_zero_range(), smb3_punch_hole(), smb3_collapse_range()
and smb3_insert_range()) do.&lt;/p&gt;
&lt;p&gt;cifs_file_copychunk_range() invalidates the destination range with
filemap_invalidate_inode(), which takes and drops the mapping&amp;#39;s
invalidate_lock internally, so the lock is no longer held when the
copychunk ioctl is issued.  It also never drains in-flight netfs I/O on
the target.  The clone path never takes the invalidate_lock at all (only
i_rwsem), uses a bare truncate_inode_pages_range() and likewise does not
drain outstanding I/O.&lt;/p&gt;
&lt;p&gt;As a result an asynchronous destination writeback can complete after the
server-side copy/clone has run and reinstate stale data over the region
just written by the server, corrupting the file.  This is the same class
of corruption as commit d7d2adcd022b (&amp;#34;smb/client: flush dirty data
before punching a hole&amp;#34;) and has been seen randomly in generic/363
against Windows Server.&lt;/p&gt;
&lt;p&gt;Fix both paths to follow the established ordering: hold the target
mapping&amp;#39;s invalidate_lock across the flush and invalidation of the
destination and the server ioctl, and call netfs_wait_for_outstanding_io()
on the target to drain in-flight writes bef…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;smb: client: drain and invalidate before server-side copy/clone&lt;/p&gt;
&lt;p&gt;cifs_file_copychunk_range() and the clone (FICLONE) path of
cifs_remap_file_range() do not serialise the destination page cache
against the server-side copy the way the other server-side range
operations (smb3_zero_range(), smb3_punch_hole(), smb3_collapse_range()
and smb3_insert_range()) do.&lt;/p&gt;
&lt;p&gt;cifs_file_copychunk_range() invalidates the destination range with
filemap_invalidate_inode(), which takes and drops the mapping&amp;#39;s
invalidate_lock internally, so the lock is no longer held when the
copychunk ioctl is issued.  It also never drains in-flight netfs I/O on
the target.  The clone path never takes the invalidate_lock at all (only
i_rwsem), uses a bare truncate_inode_pages_range() and likewise does not
drain outstanding I/O.&lt;/p&gt;
&lt;p&gt;As a result an asynchronous destination writeback can complete after the
server-side copy/clone has run and reinstate stale data over the region
just written by the server, corrupting the file.  This is the same class
of corruption as commit d7d2adcd022b (&amp;#34;smb/client: flush dirty data
before punching a hole&amp;#34;) and has been seen randomly in generic/363
against Windows Server.&lt;/p&gt;
&lt;p&gt;Fix both paths to follow the established ordering: hold the target
mapping&amp;#39;s invalidate_lock across the flush and invalidation of the
destination and the server ioctl, and call netfs_wait_for_outstanding_io()
on the target to drain in-flight writes bef…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-98682</guid>
    </item>
    <item>
      <title>GHSA-78hr-gpp6-3qpr</title>
      <link>https://db.gcve.eu/vuln/ghsa-78hr-gpp6-3qpr</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;smb: client: drain and invalidate before server-side copy/clone&lt;/p&gt;
&lt;p&gt;cifs_file_copychunk_range() and the clone (FICLONE) path of
cifs_remap_file_range() do not serialise the destination page cache
against the server-side copy the way the other server-side range
operations (smb3_zero_range(), smb3_punch_hole(), smb3_collapse_range()
and smb3_insert_range()) do.&lt;/p&gt;
&lt;p&gt;cifs_file_copychunk_range() invalidates the destination range with
filemap_invalidate_inode(), which takes and drops the mapping&amp;#39;s
invalidate_lock internally, so the lock is no longer held when the
copychunk ioctl is issued.  It also never drains in-flight netfs I/O on
the target.  The clone path never takes the invalidate_lock at all (only
i_rwsem), uses a bare truncate_inode_pages_range() and likewise does not
drain outstanding I/O.&lt;/p&gt;
&lt;p&gt;As a result an asynchronous destination writeback can complete after the
server-side copy/clone has run and reinstate stale data over the region
just written by the server, corrupting the file.  This is the same class
of corruption as commit d7d2adcd022b (&amp;#34;smb/client: flush dirty data
before punching a hole&amp;#34;) and has been seen randomly in generic/363
against Windows Server.&lt;/p&gt;
&lt;p&gt;Fix both paths to follow the established ordering: hold the target
mapping&amp;#39;s invalidate_lock across the flush and invalidation of the
destination and the server ioctl, and call netfs_wait_for_outstanding_io()
on the target to drain in-flight writes bef…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;smb: client: drain and invalidate before server-side copy/clone&lt;/p&gt;
&lt;p&gt;cifs_file_copychunk_range() and the clone (FICLONE) path of
cifs_remap_file_range() do not serialise the destination page cache
against the server-side copy the way the other server-side range
operations (smb3_zero_range(), smb3_punch_hole(), smb3_collapse_range()
and smb3_insert_range()) do.&lt;/p&gt;
&lt;p&gt;cifs_file_copychunk_range() invalidates the destination range with
filemap_invalidate_inode(), which takes and drops the mapping&amp;#39;s
invalidate_lock internally, so the lock is no longer held when the
copychunk ioctl is issued.  It also never drains in-flight netfs I/O on
the target.  The clone path never takes the invalidate_lock at all (only
i_rwsem), uses a bare truncate_inode_pages_range() and likewise does not
drain outstanding I/O.&lt;/p&gt;
&lt;p&gt;As a result an asynchronous destination writeback can complete after the
server-side copy/clone has run and reinstate stale data over the region
just written by the server, corrupting the file.  This is the same class
of corruption as commit d7d2adcd022b (&amp;#34;smb/client: flush dirty data
before punching a hole&amp;#34;) and has been seen randomly in generic/363
against Windows Server.&lt;/p&gt;
&lt;p&gt;Fix both paths to follow the established ordering: hold the target
mapping&amp;#39;s invalidate_lock across the flush and invalidation of the
destination and the server ioctl, and call netfs_wait_for_outstanding_io()
on the target to drain in-flight writes bef…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-78hr-gpp6-3qpr</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-98682 — smb: client: drain and invalidate before server-side copy/clone</title>
      <link>https://db.gcve.eu/vuln/msrc_cve-2026-98682</link>
      <description>msrc_CVE-2026-98682</description>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/msrc_cve-2026-98682</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-98682</title>
      <link>https://db.gcve.eu/vuln/ubuntu-cve-2026-98682</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 155 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: smb: client: drain and invalidate before server-side copy/clone cifs_file_copychunk_range() and the clone (FICLONE) path of cifs_remap_file_range() do not serialise the destination page cache against the server-side copy the way the other server-side range operations (smb3_zero_range(), smb3_punch_hole(), smb3_collapse_range() and smb3_insert_range()) do. cifs_file_copychunk_range() invalidates the destination range with filemap_invalidate_inode(), which takes and drops the mapping&amp;#39;s invalidate_lock internally, so the lock is no longer held when the copychunk ioctl is issued.  It also never drains in-flight netfs I/O on the target.  The clone path never takes the invalidate_lock at all (only i_rwsem), uses a bare truncate_inode_pages_range() and likewise does not drain outstanding I/O. As a result an asynchronous destination writeback can complete after the server-side copy/clone has run and reinstate stale data over the region just written by the server, corrupting the file.  This is the same class of corruption as commit d7d2adcd022b (&amp;#34;smb/client: flush dirty data before punching a hole&amp;#34;) and has been seen randomly in generic/363 against Windows Server. Fix both paths to follow the established ordering: hold the target mapping&amp;#39;s invalidate_lock across the flush and invalidation of the destination and the server ioctl, and call netfs_wait_for_outstanding_io() on the target to drain in-flight writes before t…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 155 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: smb: client: drain and invalidate before server-side copy/clone cifs_file_copychunk_range() and the clone (FICLONE) path of cifs_remap_file_range() do not serialise the destination page cache against the server-side copy the way the other server-side range operations (smb3_zero_range(), smb3_punch_hole(), smb3_collapse_range() and smb3_insert_range()) do. cifs_file_copychunk_range() invalidates the destination range with filemap_invalidate_inode(), which takes and drops the mapping&amp;#39;s invalidate_lock internally, so the lock is no longer held when the copychunk ioctl is issued.  It also never drains in-flight netfs I/O on the target.  The clone path never takes the invalidate_lock at all (only i_rwsem), uses a bare truncate_inode_pages_range() and likewise does not drain outstanding I/O. As a result an asynchronous destination writeback can complete after the server-side copy/clone has run and reinstate stale data over the region just written by the server, corrupting the file.  This is the same class of corruption as commit d7d2adcd022b (&amp;#34;smb/client: flush dirty data before punching a hole&amp;#34;) and has been seen randomly in generic/363 against Windows Server. Fix both paths to follow the established ordering: hold the target mapping&amp;#39;s invalidate_lock across the flush and invalidation of the destination and the server ioctl, and call netfs_wait_for_outstanding_io() on the target to drain in-flight writes before t…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ubuntu-cve-2026-98682</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-4019 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://db.gcve.eu/vuln/wid-sec-w-2026-4019</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, möglicherweise einen Denial-of-Service-Angriff auszulösen, Daten zu manipulieren oder offenzulegen oder Sicherheitsmaßnahmen zu umgehen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, möglicherweise einen Denial-of-Service-Angriff auszulösen, Daten zu manipulieren oder offenzulegen oder Sicherheitsmaßnahmen zu umgehen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/wid-sec-w-2026-4019</guid>
    </item>
  </channel>
</rss>
