<?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://vulnerability.circl.lu</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>Mon, 28 Sep 2026 20:20:35 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-93794</title>
      <link>https://vulnerability.circl.lu/vuln/bell-cve-2026-93794</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/bell-cve-2026-93794</guid>
    </item>
    <item>
      <title>fkie_cve-2026-93794</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-93794</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;smb/client: flush dirty data before punching a hole&lt;/p&gt;
&lt;p&gt;Punching a hole after a large buffered write may leave the range
reported as data. Reproduce it with:&lt;/p&gt;
&lt;p&gt;xfs_io -f \
    -c &amp;#34;pwrite -b 3m -S 0x61 0 3m&amp;#34; \
    -c &amp;#34;fpunch 1m 1m&amp;#34; \
    -c &amp;#34;seek -h 0&amp;#34; \
    -c &amp;#34;seek -d 1m&amp;#34; \
    /mnt/test/repro&lt;/p&gt;
&lt;p&gt;Punching 1 MiB at offset 1 MiB should produce:&lt;/p&gt;
&lt;p&gt;0          1 MiB       2 MiB       3 MiB
  |  DATA    |   HOLE    |   DATA    | EOF&lt;/p&gt;
&lt;p&gt;Instead, the entire file is reported as data. SEEK_HOLE(0) returns EOF,
and SEEK_DATA(1M) returns 1M.&lt;/p&gt;
&lt;p&gt;This happens because a dirty folio spanning the punched range can be
written back after the punch and refill the hole.&lt;/p&gt;
&lt;p&gt;Fix this by flushing and waiting for dirty data in the punched range
before invalidating the page cache and issuing FSCTL_SET_ZERO_DATA.&lt;/p&gt;
&lt;p&gt;The xfstests generic/539 pass against Samba/ksmbd with this change.&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: flush dirty data before punching a hole&lt;/p&gt;
&lt;p&gt;Punching a hole after a large buffered write may leave the range
reported as data. Reproduce it with:&lt;/p&gt;
&lt;p&gt;xfs_io -f \
    -c &amp;#34;pwrite -b 3m -S 0x61 0 3m&amp;#34; \
    -c &amp;#34;fpunch 1m 1m&amp;#34; \
    -c &amp;#34;seek -h 0&amp;#34; \
    -c &amp;#34;seek -d 1m&amp;#34; \
    /mnt/test/repro&lt;/p&gt;
&lt;p&gt;Punching 1 MiB at offset 1 MiB should produce:&lt;/p&gt;
&lt;p&gt;0          1 MiB       2 MiB       3 MiB
  |  DATA    |   HOLE    |   DATA    | EOF&lt;/p&gt;
&lt;p&gt;Instead, the entire file is reported as data. SEEK_HOLE(0) returns EOF,
and SEEK_DATA(1M) returns 1M.&lt;/p&gt;
&lt;p&gt;This happens because a dirty folio spanning the punched range can be
written back after the punch and refill the hole.&lt;/p&gt;
&lt;p&gt;Fix this by flushing and waiting for dirty data in the punched range
before invalidating the page cache and issuing FSCTL_SET_ZERO_DATA.&lt;/p&gt;
&lt;p&gt;The xfstests generic/539 pass against Samba/ksmbd with this change.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-93794</guid>
    </item>
    <item>
      <title>GHSA-5fcw-5g57-rhgg</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-5fcw-5g57-rhgg</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;smb/client: flush dirty data before punching a hole&lt;/p&gt;
&lt;p&gt;Punching a hole after a large buffered write may leave the range
reported as data. Reproduce it with:&lt;/p&gt;
&lt;p&gt;xfs_io -f \
    -c &amp;#34;pwrite -b 3m -S 0x61 0 3m&amp;#34; \
    -c &amp;#34;fpunch 1m 1m&amp;#34; \
    -c &amp;#34;seek -h 0&amp;#34; \
    -c &amp;#34;seek -d 1m&amp;#34; \
    /mnt/test/repro&lt;/p&gt;
&lt;p&gt;Punching 1 MiB at offset 1 MiB should produce:&lt;/p&gt;
&lt;p&gt;0          1 MiB       2 MiB       3 MiB
  |  DATA    |   HOLE    |   DATA    | EOF&lt;/p&gt;
&lt;p&gt;Instead, the entire file is reported as data. SEEK_HOLE(0) returns EOF,
and SEEK_DATA(1M) returns 1M.&lt;/p&gt;
&lt;p&gt;This happens because a dirty folio spanning the punched range can be
written back after the punch and refill the hole.&lt;/p&gt;
&lt;p&gt;Fix this by flushing and waiting for dirty data in the punched range
before invalidating the page cache and issuing FSCTL_SET_ZERO_DATA.&lt;/p&gt;
&lt;p&gt;The xfstests generic/539 pass against Samba/ksmbd with this change.&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: flush dirty data before punching a hole&lt;/p&gt;
&lt;p&gt;Punching a hole after a large buffered write may leave the range
reported as data. Reproduce it with:&lt;/p&gt;
&lt;p&gt;xfs_io -f \
    -c &amp;#34;pwrite -b 3m -S 0x61 0 3m&amp;#34; \
    -c &amp;#34;fpunch 1m 1m&amp;#34; \
    -c &amp;#34;seek -h 0&amp;#34; \
    -c &amp;#34;seek -d 1m&amp;#34; \
    /mnt/test/repro&lt;/p&gt;
&lt;p&gt;Punching 1 MiB at offset 1 MiB should produce:&lt;/p&gt;
&lt;p&gt;0          1 MiB       2 MiB       3 MiB
  |  DATA    |   HOLE    |   DATA    | EOF&lt;/p&gt;
&lt;p&gt;Instead, the entire file is reported as data. SEEK_HOLE(0) returns EOF,
and SEEK_DATA(1M) returns 1M.&lt;/p&gt;
&lt;p&gt;This happens because a dirty folio spanning the punched range can be
written back after the punch and refill the hole.&lt;/p&gt;
&lt;p&gt;Fix this by flushing and waiting for dirty data in the punched range
before invalidating the page cache and issuing FSCTL_SET_ZERO_DATA.&lt;/p&gt;
&lt;p&gt;The xfstests generic/539 pass against Samba/ksmbd with this change.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-5fcw-5g57-rhgg</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-93794</title>
      <link>https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-93794</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 246 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: smb/client: flush dirty data before punching a hole Punching a hole after a large buffered write may leave the range reported as data. Reproduce it with:   xfs_io -f \     -c &amp;#34;pwrite -b 3m -S 0x61 0 3m&amp;#34; \     -c &amp;#34;fpunch 1m 1m&amp;#34; \     -c &amp;#34;seek -h 0&amp;#34; \     -c &amp;#34;seek -d 1m&amp;#34; \     /mnt/test/repro Punching 1 MiB at offset 1 MiB should produce:   0          1 MiB       2 MiB       3 MiB   |  DATA    |   HOLE    |   DATA    | EOF Instead, the entire file is reported as data. SEEK_HOLE(0) returns EOF, and SEEK_DATA(1M) returns 1M. This happens because a dirty folio spanning the punched range can be written back after the punch and refill the hole. Fix this by flushing and waiting for dirty data in the punched range before invalidating the page cache and issuing FSCTL_SET_ZERO_DATA. The xfstests generic/539 pass against Samba/ksmbd with this change.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 246 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: smb/client: flush dirty data before punching a hole Punching a hole after a large buffered write may leave the range reported as data. Reproduce it with:   xfs_io -f \     -c &amp;#34;pwrite -b 3m -S 0x61 0 3m&amp;#34; \     -c &amp;#34;fpunch 1m 1m&amp;#34; \     -c &amp;#34;seek -h 0&amp;#34; \     -c &amp;#34;seek -d 1m&amp;#34; \     /mnt/test/repro Punching 1 MiB at offset 1 MiB should produce:   0          1 MiB       2 MiB       3 MiB   |  DATA    |   HOLE    |   DATA    | EOF Instead, the entire file is reported as data. SEEK_HOLE(0) returns EOF, and SEEK_DATA(1M) returns 1M. This happens because a dirty folio spanning the punched range can be written back after the punch and refill the hole. Fix this by flushing and waiting for dirty data in the punched range before invalidating the page cache and issuing FSCTL_SET_ZERO_DATA. The xfstests generic/539 pass against Samba/ksmbd with this change.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-93794</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-3579 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://vulnerability.circl.lu/vuln/wid-sec-w-2026-3579</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Zustand herbeizuführen oder nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Zustand herbeizuführen oder nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/wid-sec-w-2026-3579</guid>
    </item>
  </channel>
</rss>
