Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: timer: Fix UAF at snd_timer_user_params()<br /> <br /> At releasing a timer object, e.g. when a userspace timer<br /> (CONFIG_SND_UTIMER) gets closed and snd_timer_free() is called, it<br /> tries to detach the timer instances and release the resources.<br /> However, it&amp;#39;s still possible that other in-flight tasks are holding<br /> the timer instance where the to-be-deleted timer object is associated,<br /> and this may lead to racy accesses.<br /> <br /> Fortunately, most of ioctls dealing with the timer instance list<br /> already have the protection with register_mutex, and this also avoids<br /> such races. But, SNDRV_TIMER_IOCTL_PARAMS isn&amp;#39;t protected, hence the<br /> concurrent ioctl may lead to use-after-free.<br /> <br /> This patch just adds the guard with register_mutex to protect<br /> snd_timer_user_params() for covering the code path as a quick<br /> workaround. It&amp;#39;s no hot-path but rather a rarely issued ioctl, so the<br /> performance penalty doesn&amp;#39;t matter.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/net: inherit IORING_CQE_F_BUF_MORE across bundle recv retries<br /> <br /> When a bundle recv retries inside io_recv_finish(), the merge logic OR<br /> the saved cflags from the previous iteration with the cflags returned by<br /> the new iteration:<br /> cflags = req-&gt;cqe.flags | (cflags &amp; CQE_F_MASK);<br /> <br /> Bits listed in CQE_F_MASK are inherited from the new iteration, and all<br /> other bits (notably IORING_CQE_F_BUFFER and the buffer ID) come from the<br /> saved cflags. Before this change CQE_F_MASK covered only<br /> IORING_CQE_F_SOCK_NONEMPTY and IORING_CQE_F_MORE.<br /> <br /> When using provided buffer rings (IOU_PBUF_RING_INC) with incremental<br /> mode, and bundle recv, io_kbuf_inc_commit() can leave the head ring<br /> entry partially consumed, __io_put_kbufs() then sets<br /> IORING_CQE_F_BUF_MORE on the returned cflags so userspace knows the<br /> buffer ID will be reused for subsequent completions.<br /> <br /> Because IORING_CQE_F_BUF_MORE was not in CQE_F_MASK, the merge above<br /> silently dropped it whenever the final retry iteration partially<br /> consumed the buffer, and the subsequent req-&gt;cqe.flags = cflags &amp;<br /> ~CQE_F_MASK save would have left a stale IORING_CQE_F_BUF_MORE in the<br /> carried-over cflags had one been present. Userspace would then<br /> wrongfully advance it ring head past an entry the kernel still uses.<br /> <br /> Add IORING_CQE_F_BUF_MORE to CQE_F_MASK so it is both inherited from the<br /> new iteration into the user-visible CQE and stripped from the saved<br /> cflags between iterations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/virtio: fix dma_fence refcount leak on error in virtio_gpu_dma_fence_wait()<br /> <br /> dma_fence_unwrap_for_each() internally calls dma_fence_unwrap_first()<br /> which does cursor-&gt;chain = dma_fence_get(head), taking an extra<br /> reference. On normal loop completion, dma_fence_unwrap_next()<br /> releases this via dma_fence_chain_walk() -&gt; dma_fence_put().<br /> <br /> When virtio_gpu_do_fence_wait() fails and the function returns early<br /> from inside the loop, the cursor-&gt;chain reference is never released.<br /> This is the only caller in the entire kernel that does an early return<br /> inside dma_fence_unwrap_for_each.<br /> <br /> Add dma_fence_put(itr.chain) before the early return.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/huge_memory: update file PMD counter before folio_put()<br /> <br /> __split_huge_pmd_locked() updates the file/shmem RSS counter after<br /> dropping the PMD mapping&amp;#39;s folio reference. If folio_put() drops the last<br /> reference, mm_counter_file() can later read freed folio state via<br /> folio_test_swapbacked().<br /> <br /> Move the counter update before folio_put().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/core: Validate the passed in fops for ib_get_ucaps()<br /> <br /> Sashiko pointed out it is not safe to rely only on the devt because<br /> char/block alias so if the user finds a block device with the same dev_t<br /> it can masquerade as a ucap cdev fd.<br /> <br /> Test the f_ops to only accept authentic cdevs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/core: Validate cpu_id against nr_cpu_ids in DMAH alloc<br /> <br /> The cpu_id attribute supplied by user space through<br /> UVERBS_ATTR_ALLOC_DMAH_CPU_ID is passed directly to cpumask_test_cpu()<br /> without first verifying that the value is within the valid CPU range.<br /> <br /> Passing such untrusted data to cpumask_test_cpu() may lead to an<br /> out-of-bounds read of the underlying cpumask bitmap: the helper expands<br /> to a test_bit() that indexes the bitmap by cpu_id / BITS_PER_LONG with<br /> no bound check.<br /> <br /> In addition, on kernels built with CONFIG_DEBUG_PER_CPU_MAPS it trips<br /> the WARN_ON_ONCE() in cpumask_check(); combined with panic_on_warn this<br /> turns a bad user input into a machine reboot.<br /> <br /> Reject any cpu_id that is not smaller than nr_cpu_ids with -EINVAL<br /> before it is used.<br /> <br /> Reported by Smatch.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/srp: bound SRP_RSP sense copy by the received length<br /> <br /> srp_process_rsp() copies sense data from rsp-&gt;data + resp_data_len,<br /> where resp_data_len is the full 32-bit value supplied by the SRP target<br /> and is never checked against the number of bytes actually received<br /> (wc-&gt;byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so<br /> at most 96 bytes are copied, but the source offset is not bounded.<br /> <br /> A malicious or compromised SRP target on the InfiniBand/RoCE fabric that<br /> the initiator has logged into can return an SRP_RSP with<br /> SRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer<br /> is allocated at the target-chosen max_ti_iu_len, so the source of the<br /> sense copy lands past the bytes actually received; with resp_data_len<br /> near 0xFFFFFFFF it is gigabytes past the buffer and the read faults.<br /> <br /> Copy the sense data only if it has not been truncated, that is, only if<br /> the response header, the response data, and the sense region fit within<br /> the bytes actually received; otherwise drop the sense and log. The<br /> in-tree iSER and NVMe-RDMA receive paths already bound their parse by<br /> wc-&gt;byte_len; this brings ib_srp into line with them.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> zram: fix use-after-free in zram_bvec_write_partial()<br /> <br /> zram_read_page() picks the sync or async backing device read path based on<br /> whether the parent bio is NULL. zram_bvec_write_partial() passes its<br /> parent bio down, so for ZRAM_WB slots the read is dispatched<br /> asynchronously and zram_read_page() returns 0 while the bio is still in<br /> flight. The caller then runs memcpy_from_bvec(), zram_write_page() and<br /> __free_page() on the buffer, leaving the async read to write into a freed<br /> page.<br /> <br /> zram_bvec_read_partial() was switched to NULL in commit 4e3c87b9421d<br /> ("zram: fix synchronous reads") for the same reason; the write_partial<br /> counterpart was missed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8723bs: fix buffer over-read in rtw_update_protection<br /> <br /> rtw_update_protection() is called with a pointer offset into the<br /> ies buffer but the full ie_length is passed, causing a potential<br /> buffer over-read.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt_en: Fix NULL pointer dereference<br /> <br /> PCIe errors detected by a Root Port or Downstream Port cause error<br /> recovery services to run on all subordinate devices regardless of<br /> administrative state.<br /> <br /> The .error_detected() callback, bnxt_io_error_detected(), disables<br /> and synchronizes IRQs via bnxt_disable_int_sync(), which calls<br /> bnxt_cp_num_to_irq_num() to map completion rings to IRQs using<br /> bp-&gt;bnapi.<br /> <br /> Since bp-&gt;bnapi is allocated on NIC open and freed on NIC close, PCIe<br /> error recovery on a closed NIC can dereference a NULL pointer.<br /> <br /> Check if bp-&gt;bnapi is NULL before disabling and synchronizing IRQs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udp: clear skb-&gt;dev before running a sockmap verdict<br /> <br /> On the UDP receive path skb-&gt;dev is repurposed as dev_scratch (the<br /> truesize/state cache set by udp_set_dev_scratch()), through the<br /> union { struct net_device *dev; unsigned long dev_scratch; } in sk_buff.<br /> <br /> When a UDP socket is in a sockmap, sk_data_ready is<br /> sk_psock_verdict_data_ready(), which calls udp_read_skb() -&gt; recv_actor()<br /> (sk_psock_verdict_recv) to run the attached SK_SKB verdict program in softirq.<br /> If that program calls a socket-lookup helper (bpf_sk_lookup_tcp/udp,<br /> bpf_skc_lookup_tcp), bpf_skc_lookup() does:<br /> <br /> if (skb-&gt;dev)<br /> caller_net = dev_net(skb-&gt;dev);<br /> <br /> skb-&gt;dev still holds the dev_scratch value (a non-NULL integer), so dev_net()<br /> dereferences it as a struct net_device * and the kernel takes a general<br /> protection fault on a non-canonical address in softirq:<br /> <br /> Oops: general protection fault, probably for non-canonical address 0x1010000800004a0<br /> CPU: 1 UID: 0 PID: 1406 Comm: syz.2.19 Not tainted 7.1.0-rc6 #1 PREEMPT(full)<br /> RIP: 0010:bpf_skc_lookup net/core/filter.c:7033 [inline]<br /> RIP: 0010:bpf_sk_lookup+0x45/0x160 net/core/filter.c:7047<br /> Call Trace:<br /> <br /> bpf_prog_4675cb904b7071f8+0x12e/0x14e<br /> bpf_prog_run_pin_on_cpu+0xc6/0x1f0<br /> sk_psock_verdict_recv+0x1ba/0x350<br /> udp_read_skb+0x31a/0x370<br /> sk_psock_verdict_data_ready+0x2e3/0x600<br /> __udp_enqueue_schedule_skb+0x4c8/0x650<br /> udpv6_queue_rcv_one_skb+0x3ec/0x740<br /> udp6_unicast_rcv_skb+0x11d/0x140<br /> ip6_protocol_deliver_rcu+0x61e/0x950<br /> ip6_input_finish+0xa9/0x150<br /> NF_HOOK+0x286/0x2f0<br /> ip6_input+0x117/0x220<br /> NF_HOOK+0x286/0x2f0<br /> __netif_receive_skb+0x85/0x200<br /> process_backlog+0x374/0x9a0<br /> __napi_poll+0x4f/0x1c0<br /> net_rx_action+0x3b0/0x770<br /> handle_softirqs+0x15a/0x460<br /> do_softirq+0x57/0x80<br /> <br /> <br /> The rmem charge that dev_scratch accounted for is released by skb_recv_udp() on<br /> dequeue, just above, so the scratch is dead by the time recv_actor() runs. Clear<br /> skb-&gt;dev so bpf_skc_lookup() falls back to sock_net(skb-&gt;sk), which<br /> skb_set_owner_sk_safe() set just above.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: allow subflow rcv wnd to shrink<br /> <br /> In MPTCP connection, the `window` field in the TCP header refers to the<br /> MPTCP-level rcv_nxt and it&amp;#39;s right edge should not move backward. Such<br /> constraint is enforced at DSS option generation time.<br /> <br /> At the same time, the TCP stack ensures independently that the TCP-level<br /> rcv wnd right&amp;#39;s edge does not move backward. That in turn causes artificial<br /> inflating of the MPTCP rcv window when the incoming data is acked at the<br /> TCP level and is OoO in the MPTCP sequence space (or lands in the backlog).<br /> <br /> As a consequence, the incoming traffic can exceed the receiver rcvbuf size<br /> even when the sender is not misbehaving.<br /> <br /> Prevent such scenario forcibly allowing the TCP subflow to shrink the<br /> TCP-level rcv wnd regardless of the current netns setting.