<?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>Mon, 28 Sep 2026 19:57:23 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-95834</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-95834</link>
      <description>&lt;p&gt;Use After Free in the drag source path of the drag and drop protocol in kitty from 0.47.0 before 0.49.0 allows a program writing to the terminal to cause the terminal to read from and write to freed heap memory, because drag_remote_file_data() in kitty/dnd.c holds a DragRemoteItem pointer into an array it does not own, calls toplevel_data_for_drag() or subdir_data_for_drag(), and then continues to use that pointer. Those helpers, and add_payload() and populate_dir_entries() which they call, report errors through the abrt() macro, which expands to cancel_drag() followed by a plain return, and cancel_drag() calls drag_free_offer(), which frees the array the pointer refers to. The helpers return void, so the caller receives no indication that the teardown happened, and proceeds to call all_children_complete() on the freed pointer, which dereferences it, and then to write through it. That dereference is guarded by a local flag that is set when the request carries no payload and announces no further data, which is the same condition that selects the finalisation block of add_payload(), so the error paths in that block reach it: a create that fails because an entry of the same name already exists, because the client may declare two entries with one name and the create operations use O_CREAT with O_EXCL and symlinkat(), a mkdirat() failure other than EEXIST, and the directory entry allocation paths. Both branches reach it. In the top level branch the caller&amp;#39;s pointer is never clear…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Use After Free in the drag source path of the drag and drop protocol in kitty from 0.47.0 before 0.49.0 allows a program writing to the terminal to cause the terminal to read from and write to freed heap memory, because drag_remote_file_data() in kitty/dnd.c holds a DragRemoteItem pointer into an array it does not own, calls toplevel_data_for_drag() or subdir_data_for_drag(), and then continues to use that pointer. Those helpers, and add_payload() and populate_dir_entries() which they call, report errors through the abrt() macro, which expands to cancel_drag() followed by a plain return, and cancel_drag() calls drag_free_offer(), which frees the array the pointer refers to. The helpers return void, so the caller receives no indication that the teardown happened, and proceeds to call all_children_complete() on the freed pointer, which dereferences it, and then to write through it. That dereference is guarded by a local flag that is set when the request carries no payload and announces no further data, which is the same condition that selects the finalisation block of add_payload(), so the error paths in that block reach it: a create that fails because an entry of the same name already exists, because the client may declare two entries with one name and the create operations use O_CREAT with O_EXCL and symlinkat(), a mkdirat() failure other than EEXIST, and the directory entry allocation paths. Both branches reach it. In the top level branch the caller&amp;#39;s pointer is never clear…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-95834</guid>
    </item>
    <item>
      <title>GHSA-3v4f-mq3r-g3gv</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-3v4f-mq3r-g3gv</link>
      <description>&lt;p&gt;Use After Free in the drag source path of the drag and drop protocol in kitty from 0.47.0 before 0.49.0 allows a program writing to the terminal to cause the terminal to read from and write to freed heap memory, because drag_remote_file_data() in kitty/dnd.c holds a DragRemoteItem pointer into an array it does not own, calls toplevel_data_for_drag() or subdir_data_for_drag(), and then continues to use that pointer. Those helpers, and add_payload() and populate_dir_entries() which they call, report errors through the abrt() macro, which expands to cancel_drag() followed by a plain return, and cancel_drag() calls drag_free_offer(), which frees the array the pointer refers to. The helpers return void, so the caller receives no indication that the teardown happened, and proceeds to call all_children_complete() on the freed pointer, which dereferences it, and then to write through it. That dereference is guarded by a local flag that is set when the request carries no payload and announces no further data, which is the same condition that selects the finalisation block of add_payload(), so the error paths in that block reach it: a create that fails because an entry of the same name already exists, because the client may declare two entries with one name and the create operations use O_CREAT with O_EXCL and symlinkat(), a mkdirat() failure other than EEXIST, and the directory entry allocation paths. Both branches reach it. In the top level branch the caller&amp;#39;s pointer is never clear…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Use After Free in the drag source path of the drag and drop protocol in kitty from 0.47.0 before 0.49.0 allows a program writing to the terminal to cause the terminal to read from and write to freed heap memory, because drag_remote_file_data() in kitty/dnd.c holds a DragRemoteItem pointer into an array it does not own, calls toplevel_data_for_drag() or subdir_data_for_drag(), and then continues to use that pointer. Those helpers, and add_payload() and populate_dir_entries() which they call, report errors through the abrt() macro, which expands to cancel_drag() followed by a plain return, and cancel_drag() calls drag_free_offer(), which frees the array the pointer refers to. The helpers return void, so the caller receives no indication that the teardown happened, and proceeds to call all_children_complete() on the freed pointer, which dereferences it, and then to write through it. That dereference is guarded by a local flag that is set when the request carries no payload and announces no further data, which is the same condition that selects the finalisation block of add_payload(), so the error paths in that block reach it: a create that fails because an entry of the same name already exists, because the client may declare two entries with one name and the create operations use O_CREAT with O_EXCL and symlinkat(), a mkdirat() failure other than EEXIST, and the directory entry allocation paths. Both branches reach it. In the top level branch the caller&amp;#39;s pointer is never clear…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-3v4f-mq3r-g3gv</guid>
    </item>
  </channel>
</rss>
