<?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>Fri, 16 Oct 2026 01:15:15 +0000</lastBuildDate>
    <item>
      <title>GHSA-rvr2-r3pv-5m4p — oneshot has potential Use After Free when used asynchronously</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-rvr2-r3pv-5m4p</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: oneshot&lt;/p&gt;
&lt;p&gt;There is a race condition that can lead to a use-after-free if a `oneshot::Receiver` is polled but then dropped instead of polled to completion. This could happen if the receiver future was cancelled while receiving, for example by being wrapped in a timeout future or similar.&lt;/p&gt;
&lt;p&gt;When the `Receiver` is polled (`Future::poll`) it writes a waker to the channel and sets it to the `RECEIVING` state. If the `Receiver` was then dropped (instead of polled to completion), the `Drop` implementation on `Receiver` unconditionally swapped the channel state to `DISCONNECTED` and only after doing so it read back its waker from the heap allocation and dropped it. The problem is that the `DISCONNECTED` state could be observed by the `Sender`, which would lead to it deallocating the channel heap memory. If the `Sender` manage to free the channel before the `Receiver` managed to proceed to dropping the waker, then the `Receiver` would read from the freed channel memory (Use After Free).&lt;/p&gt;
&lt;p&gt;The fix was submitted in https://github.com/faern/oneshot/pull/74 and published as part of `oneshot` version `0.1.12`.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: oneshot&lt;/p&gt;
&lt;p&gt;There is a race condition that can lead to a use-after-free if a `oneshot::Receiver` is polled but then dropped instead of polled to completion. This could happen if the receiver future was cancelled while receiving, for example by being wrapped in a timeout future or similar.&lt;/p&gt;
&lt;p&gt;When the `Receiver` is polled (`Future::poll`) it writes a waker to the channel and sets it to the `RECEIVING` state. If the `Receiver` was then dropped (instead of polled to completion), the `Drop` implementation on `Receiver` unconditionally swapped the channel state to `DISCONNECTED` and only after doing so it read back its waker from the heap allocation and dropped it. The problem is that the `DISCONNECTED` state could be observed by the `Sender`, which would lead to it deallocating the channel heap memory. If the `Sender` manage to free the channel before the `Receiver` managed to proceed to dropping the waker, then the `Receiver` would read from the freed channel memory (Use After Free).&lt;/p&gt;
&lt;p&gt;The fix was submitted in https://github.com/faern/oneshot/pull/74 and published as part of `oneshot` version `0.1.12`.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-rvr2-r3pv-5m4p</guid>
    </item>
  </channel>
</rss>
