https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 12:35:03 +0000 https://vulnerability.circl.lu/vuln/cve-2021-47505 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>aio: fix use-after-free due to missing POLLFREE handling</p> <p>signalfd_poll() and binder_poll() are special in that they use a waitqueue whose lifetime is the current task, rather than the struct file as is normally the case. This is okay for blocking polls, since a blocking poll occurs within one task; however, non-blocking polls require another solution. This solution is for the queue to be cleared before it is freed, by sending a POLLFREE notification to all waiters.</p> <p>Unfortunately, only eventpoll handles POLLFREE. A second type of non-blocking poll, aio poll, was added in kernel v4.18, and it doesn&#39;t handle POLLFREE. This allows a use-after-free to occur if a signalfd or binder fd is polled with aio poll, and the waitqueue gets freed.</p> <p>Fix this by making aio poll handle POLLFREE.</p> <p>A patch by Ramji Jiyani &lt;ramjiyani@google.com&gt; (https://lore.kernel.org/r/20211027011834.2497484-1-ramjiyani@google.com) tried to do this by making aio_poll_wake() always complete the request inline if POLLFREE is seen. However, that solution had two bugs. First, it introduced a deadlock, as it unconditionally locked the aio context while holding the waitqueue lock, which inverts the normal locking order. Second, it didn&#39;t consider that POLLFREE notifications are missed while the request has been temporarily de-queued.</p> <p>The second problem was solved by my previous patch. This patch then properly fixes the use-after-free by…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>aio: fix use-after-free due to missing POLLFREE handling</p> <p>signalfd_poll() and binder_poll() are special in that they use a waitqueue whose lifetime is the current task, rather than the struct file as is normally the case. This is okay for blocking polls, since a blocking poll occurs within one task; however, non-blocking polls require another solution. This solution is for the queue to be cleared before it is freed, by sending a POLLFREE notification to all waiters.</p> <p>Unfortunately, only eventpoll handles POLLFREE. A second type of non-blocking poll, aio poll, was added in kernel v4.18, and it doesn&#39;t handle POLLFREE. This allows a use-after-free to occur if a signalfd or binder fd is polled with aio poll, and the waitqueue gets freed.</p> <p>Fix this by making aio poll handle POLLFREE.</p> <p>A patch by Ramji Jiyani &lt;ramjiyani@google.com&gt; (https://lore.kernel.org/r/20211027011834.2497484-1-ramjiyani@google.com) tried to do this by making aio_poll_wake() always complete the request inline if POLLFREE is seen. However, that solution had two bugs. First, it introduced a deadlock, as it unconditionally locked the aio context while holding the waitqueue lock, which inverts the normal locking order. Second, it didn&#39;t consider that POLLFREE notifications are missed while the request has been temporarily de-queued.</p> <p>The second problem was solved by my previous patch. This patch then properly fixes the use-after-free by…</p> https://vulnerability.circl.lu/vuln/cve-2021-47505