<?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>Sat, 03 Oct 2026 20:40:44 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-74599</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-74599</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-74599</guid>
    </item>
    <item>
      <title>certfr-2026-avi-1090 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian. Elles permettent à un attaquant de provo…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-1090</link>
      <description>certfr-2026-avi-1090</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-1090</guid>
    </item>
    <item>
      <title>EUVD-2026-357924</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-357924</link>
      <description>EUVD-2026-357924</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-357924</guid>
    </item>
    <item>
      <title>fkie_cve-2026-74599</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-74599</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;mm/ptdump: always stabilise against page table freeing using init_mm&lt;/p&gt;
&lt;p&gt;Previous commits have established the invariant that kernel page table
freeing is performed while an mmap read lock on init_mm is held, which
fixes races between ptdump and kernel page table freeing over init_mm.&lt;/p&gt;
&lt;p&gt;However, x86 and arm64 can perform a ptdump over an mm other than init_mm
via ptdump_walk_pgd() and since kernel memory ranges are shared across
non-kernel mm&amp;#39;s, this means that the race still exists for these cases.&lt;/p&gt;
&lt;p&gt;Fix this by acquiring a nested mmap write lock for init_mm in
ptdump_walk_pgd().&lt;/p&gt;
&lt;p&gt;This is safe as we take this after mmap write locking the mm, and nothing
acquires the init_mm lock first before locking an arbitrary mm, so no
deadlock is possible.&lt;/p&gt;
&lt;p&gt;Also update walk_page_range_debug() to assert that init_mm is write
locked, add a comment explaining why and remove some redundant code, and
eliminate the unnecessary and confusing invocation of
walk_kernel_page_table_range().&lt;/p&gt;
&lt;p&gt;We can safely remove the non-NULL check for walk.mm, as the mmap lock
asserts would NULL pointer deref if it was (and of course no callers do
this).&lt;/p&gt;
&lt;p&gt;The first point at which ptdump can race kernel page table freeing is
commit b6bdb7517c3d (&amp;#34;mm/vmalloc: add interfaces to free unmapped page
table&amp;#34;), so we target this in the Fixes tag.&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;mm/ptdump: always stabilise against page table freeing using init_mm&lt;/p&gt;
&lt;p&gt;Previous commits have established the invariant that kernel page table
freeing is performed while an mmap read lock on init_mm is held, which
fixes races between ptdump and kernel page table freeing over init_mm.&lt;/p&gt;
&lt;p&gt;However, x86 and arm64 can perform a ptdump over an mm other than init_mm
via ptdump_walk_pgd() and since kernel memory ranges are shared across
non-kernel mm&amp;#39;s, this means that the race still exists for these cases.&lt;/p&gt;
&lt;p&gt;Fix this by acquiring a nested mmap write lock for init_mm in
ptdump_walk_pgd().&lt;/p&gt;
&lt;p&gt;This is safe as we take this after mmap write locking the mm, and nothing
acquires the init_mm lock first before locking an arbitrary mm, so no
deadlock is possible.&lt;/p&gt;
&lt;p&gt;Also update walk_page_range_debug() to assert that init_mm is write
locked, add a comment explaining why and remove some redundant code, and
eliminate the unnecessary and confusing invocation of
walk_kernel_page_table_range().&lt;/p&gt;
&lt;p&gt;We can safely remove the non-NULL check for walk.mm, as the mmap lock
asserts would NULL pointer deref if it was (and of course no callers do
this).&lt;/p&gt;
&lt;p&gt;The first point at which ptdump can race kernel page table freeing is
commit b6bdb7517c3d (&amp;#34;mm/vmalloc: add interfaces to free unmapped page
table&amp;#34;), so we target this in the Fixes tag.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-74599</guid>
    </item>
    <item>
      <title>GHSA-w5r5-f3r4-g5m8</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-w5r5-f3r4-g5m8</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;mm/ptdump: always stabilise against page table freeing using init_mm&lt;/p&gt;
&lt;p&gt;Previous commits have established the invariant that kernel page table
freeing is performed while an mmap read lock on init_mm is held, which
fixes races between ptdump and kernel page table freeing over init_mm.&lt;/p&gt;
&lt;p&gt;However, x86 and arm64 can perform a ptdump over an mm other than init_mm
via ptdump_walk_pgd() and since kernel memory ranges are shared across
non-kernel mm&amp;#39;s, this means that the race still exists for these cases.&lt;/p&gt;
&lt;p&gt;Fix this by acquiring a nested mmap write lock for init_mm in
ptdump_walk_pgd().&lt;/p&gt;
&lt;p&gt;This is safe as we take this after mmap write locking the mm, and nothing
acquires the init_mm lock first before locking an arbitrary mm, so no
deadlock is possible.&lt;/p&gt;
&lt;p&gt;Also update walk_page_range_debug() to assert that init_mm is write
locked, add a comment explaining why and remove some redundant code, and
eliminate the unnecessary and confusing invocation of
walk_kernel_page_table_range().&lt;/p&gt;
&lt;p&gt;We can safely remove the non-NULL check for walk.mm, as the mmap lock
asserts would NULL pointer deref if it was (and of course no callers do
this).&lt;/p&gt;
&lt;p&gt;The first point at which ptdump can race kernel page table freeing is
commit b6bdb7517c3d (&amp;#34;mm/vmalloc: add interfaces to free unmapped page
table&amp;#34;), so we target this in the Fixes tag.&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;mm/ptdump: always stabilise against page table freeing using init_mm&lt;/p&gt;
&lt;p&gt;Previous commits have established the invariant that kernel page table
freeing is performed while an mmap read lock on init_mm is held, which
fixes races between ptdump and kernel page table freeing over init_mm.&lt;/p&gt;
&lt;p&gt;However, x86 and arm64 can perform a ptdump over an mm other than init_mm
via ptdump_walk_pgd() and since kernel memory ranges are shared across
non-kernel mm&amp;#39;s, this means that the race still exists for these cases.&lt;/p&gt;
&lt;p&gt;Fix this by acquiring a nested mmap write lock for init_mm in
ptdump_walk_pgd().&lt;/p&gt;
&lt;p&gt;This is safe as we take this after mmap write locking the mm, and nothing
acquires the init_mm lock first before locking an arbitrary mm, so no
deadlock is possible.&lt;/p&gt;
&lt;p&gt;Also update walk_page_range_debug() to assert that init_mm is write
locked, add a comment explaining why and remove some redundant code, and
eliminate the unnecessary and confusing invocation of
walk_kernel_page_table_range().&lt;/p&gt;
&lt;p&gt;We can safely remove the non-NULL check for walk.mm, as the mmap lock
asserts would NULL pointer deref if it was (and of course no callers do
this).&lt;/p&gt;
&lt;p&gt;The first point at which ptdump can race kernel page table freeing is
commit b6bdb7517c3d (&amp;#34;mm/vmalloc: add interfaces to free unmapped page
table&amp;#34;), so we target this in the Fixes tag.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-w5r5-f3r4-g5m8</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-74599 — mm/ptdump: always stabilise against page table freeing using init_mm</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-74599</link>
      <description>msrc_CVE-2026-74599</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-74599</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-74599</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-74599</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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, Ubuntu:16.04:LTS: linux-hwe-edge and 245 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: mm/ptdump: always stabilise against page table freeing using init_mm Previous commits have established the invariant that kernel page table freeing is performed while an mmap read lock on init_mm is held, which fixes races between ptdump and kernel page table freeing over init_mm. However, x86 and arm64 can perform a ptdump over an mm other than init_mm via ptdump_walk_pgd() and since kernel memory ranges are shared across non-kernel mm&amp;#39;s, this means that the race still exists for these cases. Fix this by acquiring a nested mmap write lock for init_mm in ptdump_walk_pgd(). This is safe as we take this after mmap write locking the mm, and nothing acquires the init_mm lock first before locking an arbitrary mm, so no deadlock is possible. Also update walk_page_range_debug() to assert that init_mm is write locked, add a comment explaining why and remove some redundant code, and eliminate the unnecessary and confusing invocation of walk_kernel_page_table_range(). We can safely remove the non-NULL check for walk.mm, as the mmap lock asserts would NULL pointer deref if it was (and of course no callers do this). The first point at which ptdump can race kernel page table freeing is commit b6bdb7517c3d (&amp;#34;mm/vmalloc: add interfaces to free unmapped page table&amp;#34;), so we target this in the Fixes tag.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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, Ubuntu:16.04:LTS: linux-hwe-edge and 245 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: mm/ptdump: always stabilise against page table freeing using init_mm Previous commits have established the invariant that kernel page table freeing is performed while an mmap read lock on init_mm is held, which fixes races between ptdump and kernel page table freeing over init_mm. However, x86 and arm64 can perform a ptdump over an mm other than init_mm via ptdump_walk_pgd() and since kernel memory ranges are shared across non-kernel mm&amp;#39;s, this means that the race still exists for these cases. Fix this by acquiring a nested mmap write lock for init_mm in ptdump_walk_pgd(). This is safe as we take this after mmap write locking the mm, and nothing acquires the init_mm lock first before locking an arbitrary mm, so no deadlock is possible. Also update walk_page_range_debug() to assert that init_mm is write locked, add a comment explaining why and remove some redundant code, and eliminate the unnecessary and confusing invocation of walk_kernel_page_table_range(). We can safely remove the non-NULL check for walk.mm, as the mmap lock asserts would NULL pointer deref if it was (and of course no callers do this). The first point at which ptdump can race kernel page table freeing is commit b6bdb7517c3d (&amp;#34;mm/vmalloc: add interfaces to free unmapped page table&amp;#34;), so we target this in the Fixes tag.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-74599</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-2970 — Linux Kernel: Mehrere Schwachstellen ermöglichen nicht spezifizierten Angriff</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2970</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 Sicherheitsmaßnahmen zu umgehen, einen Denial-of-Service-Zustand herbeizuführen oder vertrauliche Informationen offenzulegen.&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 Sicherheitsmaßnahmen zu umgehen, einen Denial-of-Service-Zustand herbeizuführen oder vertrauliche Informationen offenzulegen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2970</guid>
    </item>
  </channel>
</rss>
