<?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://db.gcve.eu</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>Tue, 03 Nov 2026 10:30:43 +0000</lastBuildDate>
    <item>
      <title>certfr-2026-avi-1375 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian LTS. Certaines d'entre elles permettent à…</title>
      <link>https://db.gcve.eu/vuln/certfr-2026-avi-1375</link>
      <description>certfr-2026-avi-1375</description>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/certfr-2026-avi-1375</guid>
    </item>
    <item>
      <title>fkie_cve-2026-98801</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-98801</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: restrict SO_RESERVE_MEM to TCP sockets and cap max value&lt;/p&gt;
&lt;p&gt;Commit 2bb2f5fb21b0 (&amp;#34;net: add new socket option SO_RESERVE_MEM&amp;#34;) and
commit d00c8ee31729 (&amp;#34;net: fix possible NULL deref in sock_reserve_memory&amp;#34;)
only checked sk_has_account(sk), which is true for both TCP and UDP
sockets.&lt;/p&gt;
&lt;p&gt;However, SO_RESERVE_MEM and sk_unused_reserved_mem() are currently only
supported by TCP:
- On UDP sockets, sk-&amp;gt;sk_forward_alloc is protected by
  sk-&amp;gt;sk_receive_queue.lock, whereas sock_reserve_memory() and
  sock_release_reserved_memory() only acquire lock_sock(sk). Concurrent
  UDP packet reception/release and setsockopt(SO_RESERVE_MEM) corrupt
  sk_forward_alloc and memcg accounting.
- udp_rmem_release() reclaims excess sk_forward_alloc without
  accounting for sk_unused_reserved_mem(sk).&lt;/p&gt;
&lt;p&gt;Restrict sock_reserve_memory() to TCP sockets (sk_is_tcp(sk)) for now.
Supporting SO_RESERVE_MEM for UDP (acquiring sk_receive_queue.lock and
honoring sk_unused_reserved_mem() in udp_rmem_release()) can be done in
a future net-next series if needed.&lt;/p&gt;
&lt;p&gt;In addition, reject val &amp;gt; SZ_1G with -EINVAL in
sk_setsockopt(SO_RESERVE_MEM). Without an upper bound, values near
INT_MAX cause sk_mem_pages(delta) and (pages &amp;lt;&amp;lt; PAGE_SHIFT) to overflow
32-bit signed int, corrupting sk-&amp;gt;sk_forward_alloc and
sk-&amp;gt;sk_reserved_mem. Using a page-aligned cap (SZ_1G) ensures that the
page-rounded sk-&amp;gt;sk_reserved_mem reported by getsockopt(SO_RESERVE_MEM)
can alwa…&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;net: restrict SO_RESERVE_MEM to TCP sockets and cap max value&lt;/p&gt;
&lt;p&gt;Commit 2bb2f5fb21b0 (&amp;#34;net: add new socket option SO_RESERVE_MEM&amp;#34;) and
commit d00c8ee31729 (&amp;#34;net: fix possible NULL deref in sock_reserve_memory&amp;#34;)
only checked sk_has_account(sk), which is true for both TCP and UDP
sockets.&lt;/p&gt;
&lt;p&gt;However, SO_RESERVE_MEM and sk_unused_reserved_mem() are currently only
supported by TCP:
- On UDP sockets, sk-&amp;gt;sk_forward_alloc is protected by
  sk-&amp;gt;sk_receive_queue.lock, whereas sock_reserve_memory() and
  sock_release_reserved_memory() only acquire lock_sock(sk). Concurrent
  UDP packet reception/release and setsockopt(SO_RESERVE_MEM) corrupt
  sk_forward_alloc and memcg accounting.
- udp_rmem_release() reclaims excess sk_forward_alloc without
  accounting for sk_unused_reserved_mem(sk).&lt;/p&gt;
&lt;p&gt;Restrict sock_reserve_memory() to TCP sockets (sk_is_tcp(sk)) for now.
Supporting SO_RESERVE_MEM for UDP (acquiring sk_receive_queue.lock and
honoring sk_unused_reserved_mem() in udp_rmem_release()) can be done in
a future net-next series if needed.&lt;/p&gt;
&lt;p&gt;In addition, reject val &amp;gt; SZ_1G with -EINVAL in
sk_setsockopt(SO_RESERVE_MEM). Without an upper bound, values near
INT_MAX cause sk_mem_pages(delta) and (pages &amp;lt;&amp;lt; PAGE_SHIFT) to overflow
32-bit signed int, corrupting sk-&amp;gt;sk_forward_alloc and
sk-&amp;gt;sk_reserved_mem. Using a page-aligned cap (SZ_1G) ensures that the
page-rounded sk-&amp;gt;sk_reserved_mem reported by getsockopt(SO_RESERVE_MEM)
can alwa…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-98801</guid>
    </item>
    <item>
      <title>GHSA-4vp5-jwr6-3q9m</title>
      <link>https://db.gcve.eu/vuln/ghsa-4vp5-jwr6-3q9m</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: restrict SO_RESERVE_MEM to TCP sockets and cap max value&lt;/p&gt;
&lt;p&gt;Commit 2bb2f5fb21b0 (&amp;#34;net: add new socket option SO_RESERVE_MEM&amp;#34;) and
commit d00c8ee31729 (&amp;#34;net: fix possible NULL deref in sock_reserve_memory&amp;#34;)
only checked sk_has_account(sk), which is true for both TCP and UDP
sockets.&lt;/p&gt;
&lt;p&gt;However, SO_RESERVE_MEM and sk_unused_reserved_mem() are currently only
supported by TCP:
- On UDP sockets, sk-&amp;gt;sk_forward_alloc is protected by
  sk-&amp;gt;sk_receive_queue.lock, whereas sock_reserve_memory() and
  sock_release_reserved_memory() only acquire lock_sock(sk). Concurrent
  UDP packet reception/release and setsockopt(SO_RESERVE_MEM) corrupt
  sk_forward_alloc and memcg accounting.
- udp_rmem_release() reclaims excess sk_forward_alloc without
  accounting for sk_unused_reserved_mem(sk).&lt;/p&gt;
&lt;p&gt;Restrict sock_reserve_memory() to TCP sockets (sk_is_tcp(sk)) for now.
Supporting SO_RESERVE_MEM for UDP (acquiring sk_receive_queue.lock and
honoring sk_unused_reserved_mem() in udp_rmem_release()) can be done in
a future net-next series if needed.&lt;/p&gt;
&lt;p&gt;In addition, reject val &amp;gt; SZ_1G with -EINVAL in
sk_setsockopt(SO_RESERVE_MEM). Without an upper bound, values near
INT_MAX cause sk_mem_pages(delta) and (pages &amp;lt;&amp;lt; PAGE_SHIFT) to overflow
32-bit signed int, corrupting sk-&amp;gt;sk_forward_alloc and
sk-&amp;gt;sk_reserved_mem. Using a page-aligned cap (SZ_1G) ensures that the
page-rounded sk-&amp;gt;sk_reserved_mem reported by getsockopt(SO_RESERVE_MEM)
can alwa…&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;net: restrict SO_RESERVE_MEM to TCP sockets and cap max value&lt;/p&gt;
&lt;p&gt;Commit 2bb2f5fb21b0 (&amp;#34;net: add new socket option SO_RESERVE_MEM&amp;#34;) and
commit d00c8ee31729 (&amp;#34;net: fix possible NULL deref in sock_reserve_memory&amp;#34;)
only checked sk_has_account(sk), which is true for both TCP and UDP
sockets.&lt;/p&gt;
&lt;p&gt;However, SO_RESERVE_MEM and sk_unused_reserved_mem() are currently only
supported by TCP:
- On UDP sockets, sk-&amp;gt;sk_forward_alloc is protected by
  sk-&amp;gt;sk_receive_queue.lock, whereas sock_reserve_memory() and
  sock_release_reserved_memory() only acquire lock_sock(sk). Concurrent
  UDP packet reception/release and setsockopt(SO_RESERVE_MEM) corrupt
  sk_forward_alloc and memcg accounting.
- udp_rmem_release() reclaims excess sk_forward_alloc without
  accounting for sk_unused_reserved_mem(sk).&lt;/p&gt;
&lt;p&gt;Restrict sock_reserve_memory() to TCP sockets (sk_is_tcp(sk)) for now.
Supporting SO_RESERVE_MEM for UDP (acquiring sk_receive_queue.lock and
honoring sk_unused_reserved_mem() in udp_rmem_release()) can be done in
a future net-next series if needed.&lt;/p&gt;
&lt;p&gt;In addition, reject val &amp;gt; SZ_1G with -EINVAL in
sk_setsockopt(SO_RESERVE_MEM). Without an upper bound, values near
INT_MAX cause sk_mem_pages(delta) and (pages &amp;lt;&amp;lt; PAGE_SHIFT) to overflow
32-bit signed int, corrupting sk-&amp;gt;sk_forward_alloc and
sk-&amp;gt;sk_reserved_mem. Using a page-aligned cap (SZ_1G) ensures that the
page-rounded sk-&amp;gt;sk_reserved_mem reported by getsockopt(SO_RESERVE_MEM)
can alwa…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-4vp5-jwr6-3q9m</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-98801 — net: restrict SO_RESERVE_MEM to TCP sockets and cap max value</title>
      <link>https://db.gcve.eu/vuln/msrc_cve-2026-98801</link>
      <description>msrc_CVE-2026-98801</description>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/msrc_cve-2026-98801</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-98801</title>
      <link>https://db.gcve.eu/vuln/ubuntu-cve-2026-98801</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 154 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: net: restrict SO_RESERVE_MEM to TCP sockets and cap max value Commit 2bb2f5fb21b0 (&amp;#34;net: add new socket option SO_RESERVE_MEM&amp;#34;) and commit d00c8ee31729 (&amp;#34;net: fix possible NULL deref in sock_reserve_memory&amp;#34;) only checked sk_has_account(sk), which is true for both TCP and UDP sockets. However, SO_RESERVE_MEM and sk_unused_reserved_mem() are currently only supported by TCP: - On UDP sockets, sk-&amp;gt;sk_forward_alloc is protected by   sk-&amp;gt;sk_receive_queue.lock, whereas sock_reserve_memory() and   sock_release_reserved_memory() only acquire lock_sock(sk). Concurrent   UDP packet reception/release and setsockopt(SO_RESERVE_MEM) corrupt   sk_forward_alloc and memcg accounting. - udp_rmem_release() reclaims excess sk_forward_alloc without   accounting for sk_unused_reserved_mem(sk). Restrict sock_reserve_memory() to TCP sockets (sk_is_tcp(sk)) for now. Supporting SO_RESERVE_MEM for UDP (acquiring sk_receive_queue.lock and honoring sk_unused_reserved_mem() in udp_rmem_release()) can be done in a future net-next series if needed. In addition, reject val &amp;gt; SZ_1G with -EINVAL in sk_setsockopt(SO_RESERVE_MEM). Without an upper bound, values near INT_MAX cause sk_mem_pages(delta) and (pages &amp;lt;&amp;lt; PAGE_SHIFT) to overflow 32-bit signed int, corrupting sk-&amp;gt;sk_forward_alloc and sk-&amp;gt;sk_reserved_mem. Using a page-aligned cap (SZ_1G) ensures that the page-rounded sk-&amp;gt;sk_reserved_mem reported by getsockopt(SO_RESERVE_MEM) can always be…&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 154 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: net: restrict SO_RESERVE_MEM to TCP sockets and cap max value Commit 2bb2f5fb21b0 (&amp;#34;net: add new socket option SO_RESERVE_MEM&amp;#34;) and commit d00c8ee31729 (&amp;#34;net: fix possible NULL deref in sock_reserve_memory&amp;#34;) only checked sk_has_account(sk), which is true for both TCP and UDP sockets. However, SO_RESERVE_MEM and sk_unused_reserved_mem() are currently only supported by TCP: - On UDP sockets, sk-&amp;gt;sk_forward_alloc is protected by   sk-&amp;gt;sk_receive_queue.lock, whereas sock_reserve_memory() and   sock_release_reserved_memory() only acquire lock_sock(sk). Concurrent   UDP packet reception/release and setsockopt(SO_RESERVE_MEM) corrupt   sk_forward_alloc and memcg accounting. - udp_rmem_release() reclaims excess sk_forward_alloc without   accounting for sk_unused_reserved_mem(sk). Restrict sock_reserve_memory() to TCP sockets (sk_is_tcp(sk)) for now. Supporting SO_RESERVE_MEM for UDP (acquiring sk_receive_queue.lock and honoring sk_unused_reserved_mem() in udp_rmem_release()) can be done in a future net-next series if needed. In addition, reject val &amp;gt; SZ_1G with -EINVAL in sk_setsockopt(SO_RESERVE_MEM). Without an upper bound, values near INT_MAX cause sk_mem_pages(delta) and (pages &amp;lt;&amp;lt; PAGE_SHIFT) to overflow 32-bit signed int, corrupting sk-&amp;gt;sk_forward_alloc and sk-&amp;gt;sk_reserved_mem. Using a page-aligned cap (SZ_1G) ensures that the page-rounded sk-&amp;gt;sk_reserved_mem reported by getsockopt(SO_RESERVE_MEM) can always be…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ubuntu-cve-2026-98801</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-4019 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://db.gcve.eu/vuln/wid-sec-w-2026-4019</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 einen Denial-of-Service-Angriff auszulösen, Daten zu manipulieren oder offenzulegen oder Sicherheitsmaßnahmen zu umgehen.&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 einen Denial-of-Service-Angriff auszulösen, Daten zu manipulieren oder offenzulegen oder Sicherheitsmaßnahmen zu umgehen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/wid-sec-w-2026-4019</guid>
    </item>
  </channel>
</rss>
