<?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://cve.radiocsirt.org</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>Fri, 02 Oct 2026 13:02:21 +0000</lastBuildDate>
    <item>
      <title>ALSA-2026:49211 — Important: kernel security, bug fix, and enhancement update</title>
      <link>https://cve.radiocsirt.org/vuln/alsa-2026:49211</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; AlmaLinux:10: kernel, AlmaLinux:10: kernel-64k, AlmaLinux:10: kernel-64k-core, AlmaLinux:10: kernel-64k-debug, AlmaLinux:10: kernel-64k-debug-core, AlmaLinux:10: kernel-64k-debug-devel, AlmaLinux:10: kernel-64k-debug-devel-matched, AlmaLinux:10: kernel-64k-debug-modules, AlmaLinux:10: kernel-64k-debug-modules-core, AlmaLinux:10: kernel-64k-debug-modules-extra and 65 more&lt;/p&gt;
&lt;p&gt;The kernel packages contain the Linux kernel, the core of any Linux operating system.&lt;/p&gt;
&lt;p&gt;Security Fix(es):&lt;/p&gt;
&lt;p&gt;* kernel: ksm: use range-walk function to jump over holes in scan_get_next_rmap_item (CVE-2025-68211)
  * kernel: isofs: validate Rock Ridge CE continuation extent against volume size (CVE-2026-46303)
  * kernel: net: sched: UAF via missing handler for TC_ACT_CONSUMED in tcf_qevent_handle ()&lt;/p&gt;
&lt;p&gt;Bug Fix(es) and Enhancement(s):&lt;/p&gt;
&lt;p&gt;* [DELL 10.2 FEAT] [LATE-ADD] - Include support for Ghostrider PTL mini config SKU with Realtek IC Solution [almalinux-10.2.z] (JIRA:AlmaLinux-185669)
  * dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync() [almalinux-10.2.z] (JIRA:AlmaLinux-212063)&lt;/p&gt;
&lt;p&gt;For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; AlmaLinux:10: kernel, AlmaLinux:10: kernel-64k, AlmaLinux:10: kernel-64k-core, AlmaLinux:10: kernel-64k-debug, AlmaLinux:10: kernel-64k-debug-core, AlmaLinux:10: kernel-64k-debug-devel, AlmaLinux:10: kernel-64k-debug-devel-matched, AlmaLinux:10: kernel-64k-debug-modules, AlmaLinux:10: kernel-64k-debug-modules-core, AlmaLinux:10: kernel-64k-debug-modules-extra and 65 more&lt;/p&gt;
&lt;p&gt;The kernel packages contain the Linux kernel, the core of any Linux operating system.&lt;/p&gt;
&lt;p&gt;Security Fix(es):&lt;/p&gt;
&lt;p&gt;* kernel: ksm: use range-walk function to jump over holes in scan_get_next_rmap_item (CVE-2025-68211)
  * kernel: isofs: validate Rock Ridge CE continuation extent against volume size (CVE-2026-46303)
  * kernel: net: sched: UAF via missing handler for TC_ACT_CONSUMED in tcf_qevent_handle ()&lt;/p&gt;
&lt;p&gt;Bug Fix(es) and Enhancement(s):&lt;/p&gt;
&lt;p&gt;* [DELL 10.2 FEAT] [LATE-ADD] - Include support for Ghostrider PTL mini config SKU with Realtek IC Solution [almalinux-10.2.z] (JIRA:AlmaLinux-185669)
  * dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync() [almalinux-10.2.z] (JIRA:AlmaLinux-212063)&lt;/p&gt;
&lt;p&gt;For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/alsa-2026:49211</guid>
    </item>
    <item>
      <title>BELL-CVE-2026-46303</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-46303</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://cve.radiocsirt.org/vuln/bell-cve-2026-46303</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0783 — De multiples vulnérabilités ont été découvertes dans Microsoft Azure. Elles permettent à un attaquant de provoquer une…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0783</link>
      <description>certfr-2026-avi-0783</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0783</guid>
    </item>
    <item>
      <title>EUVD-2026-364821</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-364821</link>
      <description>EUVD-2026-364821</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-364821</guid>
    </item>
    <item>
      <title>fkie_cve-2026-46303</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-46303</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;isofs: validate Rock Ridge CE continuation extent against volume size&lt;/p&gt;
&lt;p&gt;rock_continue() reads rs-&amp;gt;cont_extent verbatim from the Rock Ridge CE
record and passes it to sb_bread() without checking that the block
number is within the mounted ISO 9660 volume.  commit e595447e177b
(&amp;#34;[PATCH] rock.c: handle corrupted directories&amp;#34;) added cont_offset
and cont_size rejection for the CE continuation but did not validate
the extent block number itself.  commit f54e18f1b831 (&amp;#34;isofs: Fix
infinite looping over CE entries&amp;#34;) later capped the CE chain length
at RR_MAX_CE_ENTRIES = 32 but again left the block number unchecked.&lt;/p&gt;
&lt;p&gt;With a crafted ISO mounted via udisks2 (desktop optical auto-mount)
or via CAP_SYS_ADMIN mount, rs-&amp;gt;cont_extent can therefore point at
an out-of-range block or at blocks belonging to an adjacent
filesystem on the same block device.  sb_bread() on an out-of-range
block returns NULL cleanly via the block layer EIO path, so there
is no memory-safety violation.  For in-range reads of adjacent-
filesystem data, the CE buffer is parsed as Rock Ridge records and
only the text of SL sub-records reaches userspace through
readlink(), which makes the info-leak channel narrow and difficult
to exploit; still, rejecting the malformed CE outright matches the
rejection shape already present in the same function for
cont_offset and cont_size.&lt;/p&gt;
&lt;p&gt;Add an ISOFS_SB(sb)-&amp;gt;s_nzones bounds check to rock_continue() next
to the exis…&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;isofs: validate Rock Ridge CE continuation extent against volume size&lt;/p&gt;
&lt;p&gt;rock_continue() reads rs-&amp;gt;cont_extent verbatim from the Rock Ridge CE
record and passes it to sb_bread() without checking that the block
number is within the mounted ISO 9660 volume.  commit e595447e177b
(&amp;#34;[PATCH] rock.c: handle corrupted directories&amp;#34;) added cont_offset
and cont_size rejection for the CE continuation but did not validate
the extent block number itself.  commit f54e18f1b831 (&amp;#34;isofs: Fix
infinite looping over CE entries&amp;#34;) later capped the CE chain length
at RR_MAX_CE_ENTRIES = 32 but again left the block number unchecked.&lt;/p&gt;
&lt;p&gt;With a crafted ISO mounted via udisks2 (desktop optical auto-mount)
or via CAP_SYS_ADMIN mount, rs-&amp;gt;cont_extent can therefore point at
an out-of-range block or at blocks belonging to an adjacent
filesystem on the same block device.  sb_bread() on an out-of-range
block returns NULL cleanly via the block layer EIO path, so there
is no memory-safety violation.  For in-range reads of adjacent-
filesystem data, the CE buffer is parsed as Rock Ridge records and
only the text of SL sub-records reaches userspace through
readlink(), which makes the info-leak channel narrow and difficult
to exploit; still, rejecting the malformed CE outright matches the
rejection shape already present in the same function for
cont_offset and cont_size.&lt;/p&gt;
&lt;p&gt;Add an ISOFS_SB(sb)-&amp;gt;s_nzones bounds check to rock_continue() next
to the exis…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-46303</guid>
    </item>
    <item>
      <title>GHSA-phcq-c45r-9f84</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-phcq-c45r-9f84</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;isofs: validate Rock Ridge CE continuation extent against volume size&lt;/p&gt;
&lt;p&gt;rock_continue() reads rs-&amp;gt;cont_extent verbatim from the Rock Ridge CE
record and passes it to sb_bread() without checking that the block
number is within the mounted ISO 9660 volume.  commit e595447e177b
(&amp;#34;[PATCH] rock.c: handle corrupted directories&amp;#34;) added cont_offset
and cont_size rejection for the CE continuation but did not validate
the extent block number itself.  commit f54e18f1b831 (&amp;#34;isofs: Fix
infinite looping over CE entries&amp;#34;) later capped the CE chain length
at RR_MAX_CE_ENTRIES = 32 but again left the block number unchecked.&lt;/p&gt;
&lt;p&gt;With a crafted ISO mounted via udisks2 (desktop optical auto-mount)
or via CAP_SYS_ADMIN mount, rs-&amp;gt;cont_extent can therefore point at
an out-of-range block or at blocks belonging to an adjacent
filesystem on the same block device.  sb_bread() on an out-of-range
block returns NULL cleanly via the block layer EIO path, so there
is no memory-safety violation.  For in-range reads of adjacent-
filesystem data, the CE buffer is parsed as Rock Ridge records and
only the text of SL sub-records reaches userspace through
readlink(), which makes the info-leak channel narrow and difficult
to exploit; still, rejecting the malformed CE outright matches the
rejection shape already present in the same function for
cont_offset and cont_size.&lt;/p&gt;
&lt;p&gt;Add an ISOFS_SB(sb)-&amp;gt;s_nzones bounds check to rock_continue() next
to the exis…&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;isofs: validate Rock Ridge CE continuation extent against volume size&lt;/p&gt;
&lt;p&gt;rock_continue() reads rs-&amp;gt;cont_extent verbatim from the Rock Ridge CE
record and passes it to sb_bread() without checking that the block
number is within the mounted ISO 9660 volume.  commit e595447e177b
(&amp;#34;[PATCH] rock.c: handle corrupted directories&amp;#34;) added cont_offset
and cont_size rejection for the CE continuation but did not validate
the extent block number itself.  commit f54e18f1b831 (&amp;#34;isofs: Fix
infinite looping over CE entries&amp;#34;) later capped the CE chain length
at RR_MAX_CE_ENTRIES = 32 but again left the block number unchecked.&lt;/p&gt;
&lt;p&gt;With a crafted ISO mounted via udisks2 (desktop optical auto-mount)
or via CAP_SYS_ADMIN mount, rs-&amp;gt;cont_extent can therefore point at
an out-of-range block or at blocks belonging to an adjacent
filesystem on the same block device.  sb_bread() on an out-of-range
block returns NULL cleanly via the block layer EIO path, so there
is no memory-safety violation.  For in-range reads of adjacent-
filesystem data, the CE buffer is parsed as Rock Ridge records and
only the text of SL sub-records reaches userspace through
readlink(), which makes the info-leak channel narrow and difficult
to exploit; still, rejecting the malformed CE outright matches the
rejection shape already present in the same function for
cont_offset and cont_size.&lt;/p&gt;
&lt;p&gt;Add an ISOFS_SB(sb)-&amp;gt;s_nzones bounds check to rock_continue() next
to the exis…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-phcq-c45r-9f84</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-46303 — isofs: validate Rock Ridge CE continuation extent against volume size</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-46303</link>
      <description>msrc_CVE-2026-46303</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-46303</guid>
    </item>
    <item>
      <title>OESA-2026-3156 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2026-3156</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP4: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;drbd: add missing kref_get in handle_write_conflicts&lt;/p&gt;
&lt;p&gt;With `two-primaries` enabled, DRBD tries to detect &amp;amp;quot;concurrent&amp;amp;quot; writes
and handle write conflicts, so that even if you write to the same sector
simultaneously on both nodes, they end up with the identical data once
the writes are completed.&lt;/p&gt;
&lt;p&gt;In handling &amp;amp;quot;superseeded&amp;amp;quot; writes, we forgot a kref_get,
resulting in a premature drbd_destroy_device and use after free,
and further to kernel crashes with symptoms.&lt;/p&gt;
&lt;p&gt;Relevance: No one should use DRBD as a random data generator, and apparently
all users of &amp;amp;quot;two-primaries&amp;amp;quot; handle concurrent writes correctly on layer up.
That is cluster file systems use some distributed lock manager,
and live migration in virtualization environments stops writes on one node
before starting writes on the other node.&lt;/p&gt;
&lt;p&gt;Which means that other than for &amp;amp;quot;test cases&amp;amp;quot;,
this code path is never taken in real life.&lt;/p&gt;
&lt;p&gt;FYI, in DRBD 9, things are handled differently nowadays.  We still detect
&amp;amp;quot;write conflicts&amp;amp;quot;, but no longer try to be smart about them.
We decided to disconnect hard instead: upper layers must not submit concurrent
writes. If they do, that&amp;amp;apos;s their fault.(CVE-2025-38708)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;wifi: mwifiex: Initialize the chan_stats array to zero&lt;/p&gt;
&lt;p&gt;The adapter-&amp;amp;gt…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP4: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;drbd: add missing kref_get in handle_write_conflicts&lt;/p&gt;
&lt;p&gt;With `two-primaries` enabled, DRBD tries to detect &amp;amp;quot;concurrent&amp;amp;quot; writes
and handle write conflicts, so that even if you write to the same sector
simultaneously on both nodes, they end up with the identical data once
the writes are completed.&lt;/p&gt;
&lt;p&gt;In handling &amp;amp;quot;superseeded&amp;amp;quot; writes, we forgot a kref_get,
resulting in a premature drbd_destroy_device and use after free,
and further to kernel crashes with symptoms.&lt;/p&gt;
&lt;p&gt;Relevance: No one should use DRBD as a random data generator, and apparently
all users of &amp;amp;quot;two-primaries&amp;amp;quot; handle concurrent writes correctly on layer up.
That is cluster file systems use some distributed lock manager,
and live migration in virtualization environments stops writes on one node
before starting writes on the other node.&lt;/p&gt;
&lt;p&gt;Which means that other than for &amp;amp;quot;test cases&amp;amp;quot;,
this code path is never taken in real life.&lt;/p&gt;
&lt;p&gt;FYI, in DRBD 9, things are handled differently nowadays.  We still detect
&amp;amp;quot;write conflicts&amp;amp;quot;, but no longer try to be smart about them.
We decided to disconnect hard instead: upper layers must not submit concurrent
writes. If they do, that&amp;amp;apos;s their fault.(CVE-2025-38708)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;wifi: mwifiex: Initialize the chan_stats array to zero&lt;/p&gt;
&lt;p&gt;The adapter-&amp;amp;gt…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2026-3156</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:11014-1 — kernel-devel-7.0.12-1.1 on GA media</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:11014-1</link>
      <description>&lt;p&gt;kernel-devel-7.0.12-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel-devel-7.0.12-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2026:11014-1</guid>
    </item>
    <item>
      <title>RLSA-2026:49211 — Important: kernel security, bug fix, and enhancement update</title>
      <link>https://cve.radiocsirt.org/vuln/rlsa-2026:49211</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Rocky Linux:10: kernel&lt;/p&gt;
&lt;p&gt;The kernel packages contain the Linux kernel, the core of any Linux operating system.&lt;/p&gt;
&lt;p&gt;Security Fix(es):&lt;/p&gt;
&lt;p&gt;* kernel: ksm: use range-walk function to jump over holes in scan_get_next_rmap_item (CVE-2025-68211)&lt;/p&gt;
&lt;p&gt;* kernel: isofs: validate Rock Ridge CE continuation extent against volume size (CVE-2026-46303)&lt;/p&gt;
&lt;p&gt;* kernel: net: sched: UAF via missing handler for TC_ACT_CONSUMED in tcf_qevent_handle ()&lt;/p&gt;
&lt;p&gt;Bug Fix(es) and Enhancement(s):&lt;/p&gt;
&lt;p&gt;* [DELL 10.2 FEAT] [LATE-ADD] - Include support for Ghostrider PTL mini config SKU with Realtek IC Solution  [rhel-10.2.z] (JIRA:Rocky Linux-185669)&lt;/p&gt;
&lt;p&gt;* dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync() [rhel-10.2.z] (JIRA:Rocky Linux-212063)&lt;/p&gt;
&lt;p&gt;For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Rocky Linux:10: kernel&lt;/p&gt;
&lt;p&gt;The kernel packages contain the Linux kernel, the core of any Linux operating system.&lt;/p&gt;
&lt;p&gt;Security Fix(es):&lt;/p&gt;
&lt;p&gt;* kernel: ksm: use range-walk function to jump over holes in scan_get_next_rmap_item (CVE-2025-68211)&lt;/p&gt;
&lt;p&gt;* kernel: isofs: validate Rock Ridge CE continuation extent against volume size (CVE-2026-46303)&lt;/p&gt;
&lt;p&gt;* kernel: net: sched: UAF via missing handler for TC_ACT_CONSUMED in tcf_qevent_handle ()&lt;/p&gt;
&lt;p&gt;Bug Fix(es) and Enhancement(s):&lt;/p&gt;
&lt;p&gt;* [DELL 10.2 FEAT] [LATE-ADD] - Include support for Ghostrider PTL mini config SKU with Realtek IC Solution  [rhel-10.2.z] (JIRA:Rocky Linux-185669)&lt;/p&gt;
&lt;p&gt;* dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync() [rhel-10.2.z] (JIRA:Rocky Linux-212063)&lt;/p&gt;
&lt;p&gt;For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rlsa-2026:49211</guid>
    </item>
    <item>
      <title>SSA-019113 — SSA-019113: Vulnerabilities in the additional GNU/Linux subsystem of the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP V3.1.6</title>
      <link>https://cve.radiocsirt.org/vuln/ssa-019113</link>
      <description>&lt;p&gt;Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).&lt;/p&gt;
&lt;p&gt;Siemens has released new versions for several affected products and recommends to update to the latest versions. Siemens is preparing further fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).&lt;/p&gt;
&lt;p&gt;Siemens has released new versions for several affected products and recommends to update to the latest versions. Siemens is preparing further fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ssa-019113</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-46303</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-46303</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 253 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: isofs: validate Rock Ridge CE continuation extent against volume size rock_continue() reads rs-&amp;gt;cont_extent verbatim from the Rock Ridge CE record and passes it to sb_bread() without checking that the block number is within the mounted ISO 9660 volume.  commit e595447e177b (&amp;#34;[PATCH] rock.c: handle corrupted directories&amp;#34;) added cont_offset and cont_size rejection for the CE continuation but did not validate the extent block number itself.  commit f54e18f1b831 (&amp;#34;isofs: Fix infinite looping over CE entries&amp;#34;) later capped the CE chain length at RR_MAX_CE_ENTRIES = 32 but again left the block number unchecked. With a crafted ISO mounted via udisks2 (desktop optical auto-mount) or via CAP_SYS_ADMIN mount, rs-&amp;gt;cont_extent can therefore point at an out-of-range block or at blocks belonging to an adjacent filesystem on the same block device.  sb_bread() on an out-of-range block returns NULL cleanly via the block layer EIO path, so there is no memory-safety violation.  For in-range reads of adjacent- filesystem data, the CE buffer is parsed as Rock Ridge records and only the text of SL sub-records reaches userspace through readlink(), which makes the info-leak channel narrow and difficult to exploit; still, rejecting the malformed CE outright matches the rejection shape already present in the same function for cont_offset and cont_size. Add an ISOFS_SB(sb)-&amp;gt;s_nzones bounds check to rock_continue() next to the existing…&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 253 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: isofs: validate Rock Ridge CE continuation extent against volume size rock_continue() reads rs-&amp;gt;cont_extent verbatim from the Rock Ridge CE record and passes it to sb_bread() without checking that the block number is within the mounted ISO 9660 volume.  commit e595447e177b (&amp;#34;[PATCH] rock.c: handle corrupted directories&amp;#34;) added cont_offset and cont_size rejection for the CE continuation but did not validate the extent block number itself.  commit f54e18f1b831 (&amp;#34;isofs: Fix infinite looping over CE entries&amp;#34;) later capped the CE chain length at RR_MAX_CE_ENTRIES = 32 but again left the block number unchecked. With a crafted ISO mounted via udisks2 (desktop optical auto-mount) or via CAP_SYS_ADMIN mount, rs-&amp;gt;cont_extent can therefore point at an out-of-range block or at blocks belonging to an adjacent filesystem on the same block device.  sb_bread() on an out-of-range block returns NULL cleanly via the block layer EIO path, so there is no memory-safety violation.  For in-range reads of adjacent- filesystem data, the CE buffer is parsed as Rock Ridge records and only the text of SL sub-records reaches userspace through readlink(), which makes the info-leak channel narrow and difficult to exploit; still, rejecting the malformed CE outright matches the rejection shape already present in the same function for cont_offset and cont_size. Add an ISOFS_SB(sb)-&amp;gt;s_nzones bounds check to rock_continue() next to the existing…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-46303</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-1827 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1827</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder nicht bekannte Auswirkungen zu erzielen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder nicht bekannte Auswirkungen zu erzielen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1827</guid>
    </item>
  </channel>
</rss>
