<?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 08:43:31 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-43286</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-43286</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2026-43286</guid>
    </item>
    <item>
      <title>EUVD-2026-320992</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-320992</link>
      <description>EUVD-2026-320992</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-320992</guid>
    </item>
    <item>
      <title>fkie_cve-2026-43286</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-43286</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;mm/hugetlb: restore failed global reservations to subpool&lt;/p&gt;
&lt;p&gt;Commit a833a693a490 (&amp;#34;mm: hugetlb: fix incorrect fallback for subpool&amp;#34;)
fixed an underflow error for hstate-&amp;gt;resv_huge_pages caused by incorrectly
attributing globally requested pages to the subpool&amp;#39;s reservation.&lt;/p&gt;
&lt;p&gt;Unfortunately, this fix also introduced the opposite problem, which would
leave spool-&amp;gt;used_hpages elevated if the globally requested pages could
not be acquired.  This is because while a subpool&amp;#39;s reserve pages only
accounts for what is requested and allocated from the subpool, its &amp;#34;used&amp;#34;
counter keeps track of what is consumed in total, both from the subpool
and globally.  Thus, we need to adjust spool-&amp;gt;used_hpages in the other
direction, and make sure that globally requested pages are uncharged from
the subpool&amp;#39;s used counter.&lt;/p&gt;
&lt;p&gt;Each failed allocation attempt increments the used_hpages counter by how
many pages were requested from the global pool.  Ultimately, this renders
the subpool unusable, as used_hpages approaches the max limit.&lt;/p&gt;
&lt;p&gt;The issue can be reproduced as follows:
1. Allocate 4 hugetlb pages
2. Create a hugetlb mount with max=4, min=2
3. Consume 2 pages globally
4. Request 3 pages from the subpool (2 from subpool + 1 from global)
	4.1 hugepage_subpool_get_pages(spool, 3) succeeds.
		used_hpages += 3
	4.2 hugetlb_acct_memory(h, 1) fails: no global pages left
		used_hpages -= 2
5. Subpool now has used_hpages = 1, despite not be…&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/hugetlb: restore failed global reservations to subpool&lt;/p&gt;
&lt;p&gt;Commit a833a693a490 (&amp;#34;mm: hugetlb: fix incorrect fallback for subpool&amp;#34;)
fixed an underflow error for hstate-&amp;gt;resv_huge_pages caused by incorrectly
attributing globally requested pages to the subpool&amp;#39;s reservation.&lt;/p&gt;
&lt;p&gt;Unfortunately, this fix also introduced the opposite problem, which would
leave spool-&amp;gt;used_hpages elevated if the globally requested pages could
not be acquired.  This is because while a subpool&amp;#39;s reserve pages only
accounts for what is requested and allocated from the subpool, its &amp;#34;used&amp;#34;
counter keeps track of what is consumed in total, both from the subpool
and globally.  Thus, we need to adjust spool-&amp;gt;used_hpages in the other
direction, and make sure that globally requested pages are uncharged from
the subpool&amp;#39;s used counter.&lt;/p&gt;
&lt;p&gt;Each failed allocation attempt increments the used_hpages counter by how
many pages were requested from the global pool.  Ultimately, this renders
the subpool unusable, as used_hpages approaches the max limit.&lt;/p&gt;
&lt;p&gt;The issue can be reproduced as follows:
1. Allocate 4 hugetlb pages
2. Create a hugetlb mount with max=4, min=2
3. Consume 2 pages globally
4. Request 3 pages from the subpool (2 from subpool + 1 from global)
	4.1 hugepage_subpool_get_pages(spool, 3) succeeds.
		used_hpages += 3
	4.2 hugetlb_acct_memory(h, 1) fails: no global pages left
		used_hpages -= 2
5. Subpool now has used_hpages = 1, despite not be…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-43286</guid>
    </item>
    <item>
      <title>GHSA-ghpp-gwgc-8pq9</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-ghpp-gwgc-8pq9</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;mm/hugetlb: restore failed global reservations to subpool&lt;/p&gt;
&lt;p&gt;Commit a833a693a490 (&amp;#34;mm: hugetlb: fix incorrect fallback for subpool&amp;#34;)
fixed an underflow error for hstate-&amp;gt;resv_huge_pages caused by incorrectly
attributing globally requested pages to the subpool&amp;#39;s reservation.&lt;/p&gt;
&lt;p&gt;Unfortunately, this fix also introduced the opposite problem, which would
leave spool-&amp;gt;used_hpages elevated if the globally requested pages could
not be acquired.  This is because while a subpool&amp;#39;s reserve pages only
accounts for what is requested and allocated from the subpool, its &amp;#34;used&amp;#34;
counter keeps track of what is consumed in total, both from the subpool
and globally.  Thus, we need to adjust spool-&amp;gt;used_hpages in the other
direction, and make sure that globally requested pages are uncharged from
the subpool&amp;#39;s used counter.&lt;/p&gt;
&lt;p&gt;Each failed allocation attempt increments the used_hpages counter by how
many pages were requested from the global pool.  Ultimately, this renders
the subpool unusable, as used_hpages approaches the max limit.&lt;/p&gt;
&lt;p&gt;The issue can be reproduced as follows:
1. Allocate 4 hugetlb pages
2. Create a hugetlb mount with max=4, min=2
3. Consume 2 pages globally
4. Request 3 pages from the subpool (2 from subpool + 1 from global)
	4.1 hugepage_subpool_get_pages(spool, 3) succeeds.
		used_hpages += 3
	4.2 hugetlb_acct_memory(h, 1) fails: no global pages left
		used_hpages -= 2
5. Subpool now has used_hpages = 1, despite not be…&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/hugetlb: restore failed global reservations to subpool&lt;/p&gt;
&lt;p&gt;Commit a833a693a490 (&amp;#34;mm: hugetlb: fix incorrect fallback for subpool&amp;#34;)
fixed an underflow error for hstate-&amp;gt;resv_huge_pages caused by incorrectly
attributing globally requested pages to the subpool&amp;#39;s reservation.&lt;/p&gt;
&lt;p&gt;Unfortunately, this fix also introduced the opposite problem, which would
leave spool-&amp;gt;used_hpages elevated if the globally requested pages could
not be acquired.  This is because while a subpool&amp;#39;s reserve pages only
accounts for what is requested and allocated from the subpool, its &amp;#34;used&amp;#34;
counter keeps track of what is consumed in total, both from the subpool
and globally.  Thus, we need to adjust spool-&amp;gt;used_hpages in the other
direction, and make sure that globally requested pages are uncharged from
the subpool&amp;#39;s used counter.&lt;/p&gt;
&lt;p&gt;Each failed allocation attempt increments the used_hpages counter by how
many pages were requested from the global pool.  Ultimately, this renders
the subpool unusable, as used_hpages approaches the max limit.&lt;/p&gt;
&lt;p&gt;The issue can be reproduced as follows:
1. Allocate 4 hugetlb pages
2. Create a hugetlb mount with max=4, min=2
3. Consume 2 pages globally
4. Request 3 pages from the subpool (2 from subpool + 1 from global)
	4.1 hugepage_subpool_get_pages(spool, 3) succeeds.
		used_hpages += 3
	4.2 hugetlb_acct_memory(h, 1) fails: no global pages left
		used_hpages -= 2
5. Subpool now has used_hpages = 1, despite not be…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-ghpp-gwgc-8pq9</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-43286</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-43286</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 106 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: restore failed global reservations to subpool Commit a833a693a490 (&amp;#34;mm: hugetlb: fix incorrect fallback for subpool&amp;#34;) fixed an underflow error for hstate-&amp;gt;resv_huge_pages caused by incorrectly attributing globally requested pages to the subpool&amp;#39;s reservation. Unfortunately, this fix also introduced the opposite problem, which would leave spool-&amp;gt;used_hpages elevated if the globally requested pages could not be acquired.  This is because while a subpool&amp;#39;s reserve pages only accounts for what is requested and allocated from the subpool, its &amp;#34;used&amp;#34; counter keeps track of what is consumed in total, both from the subpool and globally.  Thus, we need to adjust spool-&amp;gt;used_hpages in the other direction, and make sure that globally requested pages are uncharged from the subpool&amp;#39;s used counter. Each failed allocation attempt increments the used_hpages counter by how many pages were requested from the global pool.  Ultimately, this renders the subpool unusable, as used_hpages approaches the max limit. The issue can be reproduced as follows: 1. Allocate 4 hugetlb pages 2. Create a hugetlb mount with max=4, min=2 3. Consume 2 pages globally 4. Request 3 pages from the subpool (2 from subpool + 1 from global) 	4.1 hugepage_subpool_get_pages(spool, 3) succeeds. 		used_hpages += 3 	4.2 hugetlb_acct_memory(h, 1) fails: no global pages left 		used_hpages -= 2 5. Subpool now has used_hpages = 1, despite not being a…&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 106 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: restore failed global reservations to subpool Commit a833a693a490 (&amp;#34;mm: hugetlb: fix incorrect fallback for subpool&amp;#34;) fixed an underflow error for hstate-&amp;gt;resv_huge_pages caused by incorrectly attributing globally requested pages to the subpool&amp;#39;s reservation. Unfortunately, this fix also introduced the opposite problem, which would leave spool-&amp;gt;used_hpages elevated if the globally requested pages could not be acquired.  This is because while a subpool&amp;#39;s reserve pages only accounts for what is requested and allocated from the subpool, its &amp;#34;used&amp;#34; counter keeps track of what is consumed in total, both from the subpool and globally.  Thus, we need to adjust spool-&amp;gt;used_hpages in the other direction, and make sure that globally requested pages are uncharged from the subpool&amp;#39;s used counter. Each failed allocation attempt increments the used_hpages counter by how many pages were requested from the global pool.  Ultimately, this renders the subpool unusable, as used_hpages approaches the max limit. The issue can be reproduced as follows: 1. Allocate 4 hugetlb pages 2. Create a hugetlb mount with max=4, min=2 3. Consume 2 pages globally 4. Request 3 pages from the subpool (2 from subpool + 1 from global) 	4.1 hugepage_subpool_get_pages(spool, 3) succeeds. 		used_hpages += 3 	4.2 hugetlb_acct_memory(h, 1) fails: no global pages left 		used_hpages -= 2 5. Subpool now has used_hpages = 1, despite not being a…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-43286</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-1454 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1454</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, Daten zu manipulieren oder offenzulegen oder einen Denial-of-Service-Zustand zu verursachen.&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, Daten zu manipulieren oder offenzulegen oder einen Denial-of-Service-Zustand zu verursachen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1454</guid>
    </item>
  </channel>
</rss>
