https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 07 Oct 2026 01:47:30 +0000 https://cve.radiocsirt.org/vuln/bell-cve-2026-63978 <p><strong>Affected:</strong> Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2026-63978 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0926 certfr-2026-avi-0926 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0926 https://cve.radiocsirt.org/vuln/euvd-2026-349549 EUVD-2026-349549 https://cve.radiocsirt.org/vuln/euvd-2026-349549 https://cve.radiocsirt.org/vuln/fkie_cve-2026-63978 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>net/handshake: Drain pending requests at net namespace exit</p> <p>The arguments to list_splice_init() in handshake_net_exit() are reversed. The call moves the local empty &#34;requests&#34; list onto hn-&gt;hn_requests, leaving the local list empty, so the subsequent drain loop runs zero iterations. Pending handshake requests that had not yet been accepted are not torn down when the net namespace is destroyed; each one keeps a reference on a socket file and on the handshake_req allocation.</p> <p>Pass the source and destination in the documented order (list_splice_init(list, head) moves list onto head) so the pending list is transferred to the local scratch list and drained through handshake_complete().</p> <p>Fixing the splice direction exposes a list-corruption race. After the splice each req-&gt;hr_list still has non-empty link pointers, threading the stack-local scratch list rather than hn_requests. A concurrent handshake_req_cancel() -- for example, from sunrpc&#39;s TLS timeout on a kernel socket whose netns reference was not taken -- finds the request through the rhashtable, calls remove_pending(), and sees !list_empty(&amp;req-&gt;hr_list). __remove_pending_locked() then list_del_init()s an entry off the scratch list while the drain iterates, corrupting it. The same call arriving after the drain loop has run list_del() on an entry hits LIST_POISON instead.</p> <p>Have remove_pending() check HANDSHAKE_F_NET_DRAINING under hn_lock and report not-fo…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>net/handshake: Drain pending requests at net namespace exit</p> <p>The arguments to list_splice_init() in handshake_net_exit() are reversed. The call moves the local empty &#34;requests&#34; list onto hn-&gt;hn_requests, leaving the local list empty, so the subsequent drain loop runs zero iterations. Pending handshake requests that had not yet been accepted are not torn down when the net namespace is destroyed; each one keeps a reference on a socket file and on the handshake_req allocation.</p> <p>Pass the source and destination in the documented order (list_splice_init(list, head) moves list onto head) so the pending list is transferred to the local scratch list and drained through handshake_complete().</p> <p>Fixing the splice direction exposes a list-corruption race. After the splice each req-&gt;hr_list still has non-empty link pointers, threading the stack-local scratch list rather than hn_requests. A concurrent handshake_req_cancel() -- for example, from sunrpc&#39;s TLS timeout on a kernel socket whose netns reference was not taken -- finds the request through the rhashtable, calls remove_pending(), and sees !list_empty(&amp;req-&gt;hr_list). __remove_pending_locked() then list_del_init()s an entry off the scratch list while the drain iterates, corrupting it. The same call arriving after the drain loop has run list_del() on an entry hits LIST_POISON instead.</p> <p>Have remove_pending() check HANDSHAKE_F_NET_DRAINING under hn_lock and report not-fo…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-63978 https://cve.radiocsirt.org/vuln/ghsa-2g7m-7wmg-84j3 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>net/handshake: Drain pending requests at net namespace exit</p> <p>The arguments to list_splice_init() in handshake_net_exit() are reversed. The call moves the local empty &#34;requests&#34; list onto hn-&gt;hn_requests, leaving the local list empty, so the subsequent drain loop runs zero iterations. Pending handshake requests that had not yet been accepted are not torn down when the net namespace is destroyed; each one keeps a reference on a socket file and on the handshake_req allocation.</p> <p>Pass the source and destination in the documented order (list_splice_init(list, head) moves list onto head) so the pending list is transferred to the local scratch list and drained through handshake_complete().</p> <p>Fixing the splice direction exposes a list-corruption race. After the splice each req-&gt;hr_list still has non-empty link pointers, threading the stack-local scratch list rather than hn_requests. A concurrent handshake_req_cancel() -- for example, from sunrpc&#39;s TLS timeout on a kernel socket whose netns reference was not taken -- finds the request through the rhashtable, calls remove_pending(), and sees !list_empty(&amp;req-&gt;hr_list). __remove_pending_locked() then list_del_init()s an entry off the scratch list while the drain iterates, corrupting it. The same call arriving after the drain loop has run list_del() on an entry hits LIST_POISON instead.</p> <p>Have remove_pending() check HANDSHAKE_F_NET_DRAINING under hn_lock and report not-fo…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>net/handshake: Drain pending requests at net namespace exit</p> <p>The arguments to list_splice_init() in handshake_net_exit() are reversed. The call moves the local empty &#34;requests&#34; list onto hn-&gt;hn_requests, leaving the local list empty, so the subsequent drain loop runs zero iterations. Pending handshake requests that had not yet been accepted are not torn down when the net namespace is destroyed; each one keeps a reference on a socket file and on the handshake_req allocation.</p> <p>Pass the source and destination in the documented order (list_splice_init(list, head) moves list onto head) so the pending list is transferred to the local scratch list and drained through handshake_complete().</p> <p>Fixing the splice direction exposes a list-corruption race. After the splice each req-&gt;hr_list still has non-empty link pointers, threading the stack-local scratch list rather than hn_requests. A concurrent handshake_req_cancel() -- for example, from sunrpc&#39;s TLS timeout on a kernel socket whose netns reference was not taken -- finds the request through the rhashtable, calls remove_pending(), and sees !list_empty(&amp;req-&gt;hr_list). __remove_pending_locked() then list_del_init()s an entry off the scratch list while the drain iterates, corrupting it. The same call arriving after the drain loop has run list_del() on an entry hits LIST_POISON instead.</p> <p>Have remove_pending() check HANDSHAKE_F_NET_DRAINING under hn_lock and report not-fo…</p> https://cve.radiocsirt.org/vuln/ghsa-2g7m-7wmg-84j3 https://cve.radiocsirt.org/vuln/msrc_cve-2026-63978 msrc_CVE-2026-63978 https://cve.radiocsirt.org/vuln/msrc_cve-2026-63978 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-63978 <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 153 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: net/handshake: Drain pending requests at net namespace exit The arguments to list_splice_init() in handshake_net_exit() are reversed. The call moves the local empty &#34;requests&#34; list onto hn-&gt;hn_requests, leaving the local list empty, so the subsequent drain loop runs zero iterations. Pending handshake requests that had not yet been accepted are not torn down when the net namespace is destroyed; each one keeps a reference on a socket file and on the handshake_req allocation. Pass the source and destination in the documented order (list_splice_init(list, head) moves list onto head) so the pending list is transferred to the local scratch list and drained through handshake_complete(). Fixing the splice direction exposes a list-corruption race. After the splice each req-&gt;hr_list still has non-empty link pointers, threading the stack-local scratch list rather than hn_requests. A concurrent handshake_req_cancel() -- for example, from sunrpc&#39;s TLS timeout on a kernel socket whose netns reference was not taken -- finds the request through the rhashtable, calls remove_pending(), and sees !list_empty(&amp;req-&gt;hr_list). __remove_pending_locked() then list_del_init()s an entry off the scratch list while the drain iterates, corrupting it. The same call arriving after the drain loop has run list_del() on an entry hits LIST_POISON instead. Have remove_pending() check HANDSHAKE_F_NET_DRAINING under hn_lock and report not-found w…</p> <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 153 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: net/handshake: Drain pending requests at net namespace exit The arguments to list_splice_init() in handshake_net_exit() are reversed. The call moves the local empty &#34;requests&#34; list onto hn-&gt;hn_requests, leaving the local list empty, so the subsequent drain loop runs zero iterations. Pending handshake requests that had not yet been accepted are not torn down when the net namespace is destroyed; each one keeps a reference on a socket file and on the handshake_req allocation. Pass the source and destination in the documented order (list_splice_init(list, head) moves list onto head) so the pending list is transferred to the local scratch list and drained through handshake_complete(). Fixing the splice direction exposes a list-corruption race. After the splice each req-&gt;hr_list still has non-empty link pointers, threading the stack-local scratch list rather than hn_requests. A concurrent handshake_req_cancel() -- for example, from sunrpc&#39;s TLS timeout on a kernel socket whose netns reference was not taken -- finds the request through the rhashtable, calls remove_pending(), and sees !list_empty(&amp;req-&gt;hr_list). __remove_pending_locked() then list_del_init()s an entry off the scratch list while the drain iterates, corrupting it. The same call arriving after the drain loop has run list_del() on an entry hits LIST_POISON instead. Have remove_pending() check HANDSHAKE_F_NET_DRAINING under hn_lock and report not-found w…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-63978 https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2403 <p>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.</p> <p>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.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2403