<html>
<head>
<base href="https://bugzilla.gnome.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - File descriptor leak in gdk_wayland_selection_request_target()"
href="https://bugzilla.gnome.org/show_bug.cgi?id=751414#c1">Comment # 1</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - File descriptor leak in gdk_wayland_selection_request_target()"
href="https://bugzilla.gnome.org/show_bug.cgi?id=751414">bug 751414</a>
from <span class="vcard"><a href="page.cgi?id=describeuser.html&login=mcatanzaro%40gnome.org" title="Michael Catanzaro <mcatanzaro@gnome.org>"> <span class="fn">Michael Catanzaro</span></a>
</span></b>
<pre>Created <span class=""><a href="attachment.cgi?id=305963&action=diff" name="attach_305963" title="GdkSelectionWayland: Fix file descriptor leak">attachment 305963</a> <a href="attachment.cgi?id=305963&action=edit" title="GdkSelectionWayland: Fix file descriptor leak">[details]</a></span> <a href='review?bug=751414&attachment=305963'>[review]</a>
GdkSelectionWayland: Fix file descriptor leak
I discovered that gdk_wayland_selection_request_target() does not
close() wayland_selection->stored_selection.fd before assigning a new fd
to it. A malicious Wayland client can trick a user into dragging data to
it from a GTK+ app, and then cause the GTK+ app to leak an arbitrary
number of file descriptors up to its limit by calling
wl_data_offer_receive() in a loop. This probably also works against any
GTK+ app that has placed data in the clipboard, though I didn't test
that.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>