CVE-2023-53461

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: wait interruptibly for request completions on exit<br /> <br /> WHen the ring exits, cleanup is done and the final cancelation and<br /> waiting on completions is done by io_ring_exit_work. That function is<br /> invoked by kworker, which doesn&amp;#39;t take any signals. Because of that, it<br /> doesn&amp;#39;t really matter if we wait for completions in TASK_INTERRUPTIBLE<br /> or TASK_UNINTERRUPTIBLE state. However, it does matter to the hung task<br /> detection checker!<br /> <br /> Normally we expect cancelations and completions to happen rather<br /> quickly. Some test cases, however, will exit the ring and park the<br /> owning task stopped (eg via SIGSTOP). If the owning task needs to run<br /> task_work to complete requests, then io_ring_exit_work won&amp;#39;t make any<br /> progress until the task is runnable again. Hence io_ring_exit_work can<br /> trigger the hung task detection, which is particularly problematic if<br /> panic-on-hung-task is enabled.<br /> <br /> As the ring exit doesn&amp;#39;t take signals to begin with, have it wait<br /> interruptibly rather than uninterruptibly. io_uring has a separate<br /> stuck-exit warning that triggers independently anyway, so we&amp;#39;re not<br /> really missing anything by making this switch.