<?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://vulnerability.circl.lu</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, 29 Sep 2026 14:15:23 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-64523 — net/handshake: Take a long-lived file reference at submit</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-64523</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net/handshake: Take a long-lived file reference at submit&lt;/p&gt;
&lt;p&gt;handshake_nl_accept_doit() needs the file pointer backing
req-&amp;gt;hr_sk-&amp;gt;sk_socket to survive the window between
handshake_req_next() and the subsequent FD_PREPARE() and get_file().
The submit-side sock_hold() does not provide that.  sk_refcnt keeps
struct sock alive, but struct socket is owned by sock-&amp;gt;file: when
the consumer fputs the last file reference, sock_release() tears
the socket down regardless of any sock_hold.&lt;/p&gt;
&lt;p&gt;Add an hr_file pointer to struct handshake_req and acquire an
explicit reference on sock-&amp;gt;file during handshake_req_submit().
handshake_complete() and handshake_req_cancel() release the
reference on the completion-bit-winning path.&lt;/p&gt;
&lt;p&gt;The submit error path must also release the file reference, but
after rhashtable insertion a concurrent handshake_req_cancel() can
discover the request and race the error path.  Gate the error-path
cleanup -- sk_destruct restoration, fput, and request destruction
-- with test_and_set_bit(HANDSHAKE_F_REQ_COMPLETED), the same
serialization handshake_complete() and handshake_req_cancel()
already use.  When cancel has already claimed ownership, the submit
error path returns without touching the request; socket teardown
handles final destruction.&lt;/p&gt;
&lt;p&gt;The accept-side dereferences are not yet retargeted; that change
comes in the next patch.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net/handshake: Take a long-lived file reference at submit&lt;/p&gt;
&lt;p&gt;handshake_nl_accept_doit() needs the file pointer backing
req-&amp;gt;hr_sk-&amp;gt;sk_socket to survive the window between
handshake_req_next() and the subsequent FD_PREPARE() and get_file().
The submit-side sock_hold() does not provide that.  sk_refcnt keeps
struct sock alive, but struct socket is owned by sock-&amp;gt;file: when
the consumer fputs the last file reference, sock_release() tears
the socket down regardless of any sock_hold.&lt;/p&gt;
&lt;p&gt;Add an hr_file pointer to struct handshake_req and acquire an
explicit reference on sock-&amp;gt;file during handshake_req_submit().
handshake_complete() and handshake_req_cancel() release the
reference on the completion-bit-winning path.&lt;/p&gt;
&lt;p&gt;The submit error path must also release the file reference, but
after rhashtable insertion a concurrent handshake_req_cancel() can
discover the request and race the error path.  Gate the error-path
cleanup -- sk_destruct restoration, fput, and request destruction
-- with test_and_set_bit(HANDSHAKE_F_REQ_COMPLETED), the same
serialization handshake_complete() and handshake_req_cancel()
already use.  When cancel has already claimed ownership, the submit
error path returns without touching the request; socket teardown
handles final destruction.&lt;/p&gt;
&lt;p&gt;The accept-side dereferences are not yet retargeted; that change
comes in the next patch.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-64523</guid>
    </item>
  </channel>
</rss>
