CVE-2021-47505

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> aio: fix use-after-free due to missing POLLFREE handling<br /> <br /> signalfd_poll() and binder_poll() are special in that they use a<br /> waitqueue whose lifetime is the current task, rather than the struct<br /> file as is normally the case. This is okay for blocking polls, since a<br /> blocking poll occurs within one task; however, non-blocking polls<br /> require another solution. This solution is for the queue to be cleared<br /> before it is freed, by sending a POLLFREE notification to all waiters.<br /> <br /> Unfortunately, only eventpoll handles POLLFREE. A second type of<br /> non-blocking poll, aio poll, was added in kernel v4.18, and it doesn&amp;#39;t<br /> handle POLLFREE. This allows a use-after-free to occur if a signalfd or<br /> binder fd is polled with aio poll, and the waitqueue gets freed.<br /> <br /> Fix this by making aio poll handle POLLFREE.<br /> <br /> A patch by Ramji Jiyani <br /> (https://lore.kernel.org/r/20211027011834.2497484-1-ramjiyani@google.com)<br /> tried to do this by making aio_poll_wake() always complete the request<br /> inline if POLLFREE is seen. However, that solution had two bugs.<br /> First, it introduced a deadlock, as it unconditionally locked the aio<br /> context while holding the waitqueue lock, which inverts the normal<br /> locking order. Second, it didn&amp;#39;t consider that POLLFREE notifications<br /> are missed while the request has been temporarily de-queued.<br /> <br /> The second problem was solved by my previous patch. This patch then<br /> properly fixes the use-after-free by handling POLLFREE in a<br /> deadlock-free way. It does this by taking advantage of the fact that<br /> freeing of the waitqueue is RCU-delayed, similar to what eventpoll does.