CVE-2020-29374

A NULL pointer dereference in the Linux GPU driver could potentially lead to a kernel crash. This may result in a denial of service on the affected system.

A use-after-free (UAF) vulnerability exists in the Linux kernel's reqsk_timer_handler() function. When TCP socket migration fails at inet_ehash_insert(), the code jumps to the no_ownership label and immediately frees the new reqsk via __reqsk_free() without stopping its timer, potentially leading to a UAF.

In the Linux kernel sched_ext scheduler, a task can be found on a non-local DSQ while the CPU that dispatched it is still running ops.dequeue() and hasn't cleared SCX_OPSS_DISPATCHING. The DSQ consume and move paths don't wait for dispatch to finish and can operate on the task concurrently with the dispatcher. The fix adds scx_wait_dispatching() before operating on the task.

In io_uring with IORING_SETUP_DEFER_TASKRUN, completions are queued as local work and only become CQEs when the submitter enters the kernel to wait for events. io_uring_poll() reports EPOLLIN if local work is pending, but only if the work exists at call time; after DEFER_TASKRUN was added, the ->poll_wq wakeup was replaced by directly waking the submitter, so poll() can sleep despite pending work. The fix wakes ->poll_wq when the first entry is put on the work list, using an RCU callback when needed.

In io_uring NAPI with dynamic tracking, a NAPI id not seen for a minute should be dropped from the ring's busy-poll list. However, the timeout is computed incorrectly — SEC_CONVERSION is used instead of the number of jiffies per second, giving about eight years for HZ=1000 and overflowing on 32-bit systems. As a result, entries are never removed and every wait polls all historical ids.

In io_uring zcrx, io_zcrx_queue_cqe() computes the buffer offset in its area from net_iov_idx(), which is an unsigned int, so the shift is done in 32 bits and only the result is widened to the u64 placed in the CQE. An area can be up to 1 TB, so for every niov beyond the first 4 GB the CQE points the application at a buffer 4 GB (or a multiple) below the correct one. The application reads wrong data and returns a buffer it doesn't own via the refill queue while the real one is never given back.

In io_uring/openclose, io_pipe_fixed() installs both ends of the pipe in the fixed file table, drops ->uring_lock, and copies the slot numbers to the application. If that faults, it takes the lock again and removes whatever is in these slots. If the request is run by io-wq, the lock really is dropped and the slots are visible to others; by the time the error path gets to them, they may have been closed and reused (by IORING_OP_CLOSE, direct open/accept, or IORING_REGISTER_FILES_UPDATE), causing removal of a file unrelated to the failed request. The fix performs the copy with the lock held.

A bug was fixed in the Linux kernel's io_uring/net handling of recv retries on uncommitted buffers. When a receive was retried after a partial transfer, the kernel could hand out buffer memory that the retried request was still writing to, causing data overwrites. The request is now completed with the bytes received instead of retried, and MSG_WAITALL is no longer honoured for incremental buffers or multi-buffer bundles.

In io_uring/poll, if a wakeup sets IO_POLL_RETRY_FLAG between the owning task consuming the existing instance of IO_POLL_RETRY_FLAG and the loop check in io_poll_check_events(), request processing stalls until an unrelated wakeup arrives. The fix uses atomic_cmpxchg instead of atomic_sub_return to guarantee both the count v and poll_refs are 0 and no wakeups are missed.

In io_uring/timeout, an IORING_OP_TIMEOUT run by io-wq due to IOSQE_ASYNC has the same problem as poll, futex, and waitid. io_wq_submit_work() checks IO_WQ_WORK_CANCEL only once before issuing the request; a cancel in between flags the work, gets -EALREADY, and searches ->timeout_list in vain while the worker adds the request and starts the timer. Nobody checks the flag again and the timeout runs its course, and at ring exit a task can get stuck for the full duration. The fix checks the flag under ->timeout_lock and fails the request if set.