<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-02T17:50:07.439690+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/bell-cve-2026-90200</id>
    <title>BELL-CVE-2026-90200</title>
    <updated>2026-10-02T17:50:07.571501+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/bell-cve-2026-90200"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/certfr-2026-avi-1253</id>
    <title>certfr-2026-avi-1253 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian. Certaines d'entre elles permettent à un…</title>
    <updated>2026-10-02T17:50:07.571554+00:00</updated>
    <content>certfr-2026-avi-1253</content>
    <link href="https://cve.radiocsirt.org/vuln/certfr-2026-avi-1253"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-370889</id>
    <title>EUVD-2026-370889</title>
    <updated>2026-10-02T17:50:07.571575+00:00</updated>
    <content>EUVD-2026-370889</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-370889"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2026-90200</id>
    <title>fkie_cve-2026-90200</title>
    <updated>2026-10-02T17:50:07.571589+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>fs/ntfs3: fix integer overflow in MFT cluster validation</p>
<p>In ntfs_init_from_boot(), the boot sector's MFT cluster numbers are
validated against the volume size with:</p>
<p>if (mlcn  * sct_per_clst &gt;= sectors ||
	    mlcn2 * sct_per_clst &gt;= sectors)
		goto out;</p>
<p>mlcn and mlcn2 are u64 fields read directly from the boot sector.
sct_per_clst is bounded above by 4096 (true_sectors_per_clst() plus
the is_power_of_2() check below it), but the multiplication is done
in u64 and wraps when mlcn (or mlcn2) is large enough -- e.g. mlcn
near 2^62 with sct_per_clst == 4 wraps to 0, which compares below
any non-zero 'sectors', so the check is bypassed and the malformed
record is accepted.</p>
<p>The accepted mlcn is then used unchanged in</p>
<p>sbi-&gt;mft.lbo = mlcn &lt;&lt; cluster_bits;</p>
<p>In practice the resulting reads fail at the block layer (sb_bread()
returns NULL via grow_buffers()'s check_mul_overflow() guard), so
today this manifests as mount failing in odd places rather than as
something more dangerous, but the validation step is still wrong
and there is no reason for callers to rely on the block layer to
catch a value that should never have been accepted in the first
place.</p>
<p>Use check_mul_overflow() to compute the two sector positions and
fail the mount if either multiplication wraps; this preserves the
existing semantics (mlcn * sct_per_clst &gt;= sectors) instead of
switching to division (mlcn &gt;= sectors / sct_per_clst), which
would…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2026-90200"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-h945-5whj-h8mc</id>
    <title>GHSA-h945-5whj-h8mc</title>
    <updated>2026-10-02T17:50:07.571638+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>fs/ntfs3: fix integer overflow in MFT cluster validation</p>
<p>In ntfs_init_from_boot(), the boot sector's MFT cluster numbers are
validated against the volume size with:</p>
<p>if (mlcn  * sct_per_clst &gt;= sectors ||
	    mlcn2 * sct_per_clst &gt;= sectors)
		goto out;</p>
<p>mlcn and mlcn2 are u64 fields read directly from the boot sector.
sct_per_clst is bounded above by 4096 (true_sectors_per_clst() plus
the is_power_of_2() check below it), but the multiplication is done
in u64 and wraps when mlcn (or mlcn2) is large enough -- e.g. mlcn
near 2^62 with sct_per_clst == 4 wraps to 0, which compares below
any non-zero 'sectors', so the check is bypassed and the malformed
record is accepted.</p>
<p>The accepted mlcn is then used unchanged in</p>
<p>sbi-&gt;mft.lbo = mlcn &lt;&lt; cluster_bits;</p>
<p>In practice the resulting reads fail at the block layer (sb_bread()
returns NULL via grow_buffers()'s check_mul_overflow() guard), so
today this manifests as mount failing in odd places rather than as
something more dangerous, but the validation step is still wrong
and there is no reason for callers to rely on the block layer to
catch a value that should never have been accepted in the first
place.</p>
<p>Use check_mul_overflow() to compute the two sector positions and
fail the mount if either multiplication wraps; this preserves the
existing semantics (mlcn * sct_per_clst &gt;= sectors) instead of
switching to division (mlcn &gt;= sectors / sct_per_clst), which
would…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-h945-5whj-h8mc"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/opensuse-su-2026:11880-1</id>
    <title>openSUSE-SU-2026:11880-1 — kernel-devel-7.2.7-1.1 on GA media</title>
    <updated>2026-10-02T17:50:07.571674+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>kernel-devel-7.2.7-1.1 on GA media</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/opensuse-su-2026:11880-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-90200</id>
    <title>UBUNTU-CVE-2026-90200</title>
    <updated>2026-10-02T17:50:07.572169+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> 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 193 more</p>
<p>In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix integer overflow in MFT cluster validation In ntfs_init_from_boot(), the boot sector's MFT cluster numbers are validated against the volume size with: 	if (mlcn  * sct_per_clst &gt;= sectors || 	    mlcn2 * sct_per_clst &gt;= sectors) 		goto out; mlcn and mlcn2 are u64 fields read directly from the boot sector. sct_per_clst is bounded above by 4096 (true_sectors_per_clst() plus the is_power_of_2() check below it), but the multiplication is done in u64 and wraps when mlcn (or mlcn2) is large enough -- e.g. mlcn near 2^62 with sct_per_clst == 4 wraps to 0, which compares below any non-zero 'sectors', so the check is bypassed and the malformed record is accepted. The accepted mlcn is then used unchanged in 	sbi-&gt;mft.lbo = mlcn &lt;&lt; cluster_bits; In practice the resulting reads fail at the block layer (sb_bread() returns NULL via grow_buffers()'s check_mul_overflow() guard), so today this manifests as mount failing in odd places rather than as something more dangerous, but the validation step is still wrong and there is no reason for callers to rely on the block layer to catch a value that should never have been accepted in the first place. Use check_mul_overflow() to compute the two sector positions and fail the mount if either multiplication wraps; this preserves the existing semantics (mlcn * sct_per_clst &gt;= sectors) instead of switching to division (mlcn &gt;= sectors / sct_per_clst), which would tighten…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-90200"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-3444</id>
    <title>WID-SEC-W-2026-3444 — Linux Kernel: Mehrere Schwachstellen</title>
    <updated>2026-10-02T17:50:07.572440+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel möglicherweise ausnutzen, um Berechtigungen zu erweitern, Sicherheitsmaßnahmen zu umgehen, Daten offenzulegen oder zu manipulieren, den Speicher zu beschädigen, Denial-of-Service-Zustände zu verursachen oder andere, nicht näher spezifizierte Angriffe durchzuführen.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/wid-sec-w-2026-3444"/>
  </entry>
</feed>
