Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing/timerlat: Drop interface_lock in stop_kthread()<br /> <br /> stop_kthread() is the offline callback for "trace/osnoise:online", since<br /> commit 5bfbcd1ee57b ("tracing/timerlat: Add interface_lock around clearing<br /> of kthread in stop_kthread()"), the following ABBA deadlock scenario is<br /> introduced:<br /> <br /> T1 | T2 [BP] | T3 [AP]<br /> osnoise_hotplug_workfn() | work_for_cpu_fn() | cpuhp_thread_fun()<br /> | _cpu_down() | osnoise_cpu_die()<br /> mutex_lock(&amp;interface_lock) | | stop_kthread()<br /> | cpus_write_lock() | mutex_lock(&amp;interface_lock)<br /> cpus_read_lock() | cpuhp_kick_ap() |<br /> <br /> As the interface_lock here in just for protecting the "kthread" field of<br /> the osn_var, use xchg() instead to fix this issue. Also use<br /> for_each_online_cpu() back in stop_per_cpu_kthreads() as it can take<br /> cpu_read_lock() again.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vrf: revert "vrf: Remove unnecessary RCU-bh critical section"<br /> <br /> This reverts commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853.<br /> <br /> dev_queue_xmit_nit is expected to be called with BH disabled.<br /> __dev_queue_xmit has the following:<br /> <br /> /* Disable soft irqs for various locks below. Also<br /> * stops preemption for RCU.<br /> */<br /> rcu_read_lock_bh();<br /> <br /> VRF must follow this invariant. The referenced commit removed this<br /> protection. Which triggered a lockdep warning:<br /> <br /> ================================<br /> WARNING: inconsistent lock state<br /> 6.11.0 #1 Tainted: G W<br /> --------------------------------<br /> inconsistent {IN-SOFTIRQ-W} -&gt; {SOFTIRQ-ON-W} usage.<br /> btserver/134819 [HC0[0]:SC0[0]:HE1:SE1] takes:<br /> ffff8882da30c118 (rlock-AF_PACKET){+.?.}-{2:2}, at: tpacket_rcv+0x863/0x3b30<br /> {IN-SOFTIRQ-W} state was registered at:<br /> lock_acquire+0x19a/0x4f0<br /> _raw_spin_lock+0x27/0x40<br /> packet_rcv+0xa33/0x1320<br /> __netif_receive_skb_core.constprop.0+0xcb0/0x3a90<br /> __netif_receive_skb_list_core+0x2c9/0x890<br /> netif_receive_skb_list_internal+0x610/0xcc0<br /> [...]<br /> <br /> other info that might help us debug this:<br /> Possible unsafe locking scenario:<br /> <br /> CPU0<br /> ----<br /> lock(rlock-AF_PACKET);<br /> <br /> lock(rlock-AF_PACKET);<br /> <br /> *** DEADLOCK ***<br /> <br /> Call Trace:<br /> <br /> dump_stack_lvl+0x73/0xa0<br /> mark_lock+0x102e/0x16b0<br /> __lock_acquire+0x9ae/0x6170<br /> lock_acquire+0x19a/0x4f0<br /> _raw_spin_lock+0x27/0x40<br /> tpacket_rcv+0x863/0x3b30<br /> dev_queue_xmit_nit+0x709/0xa40<br /> vrf_finish_direct+0x26e/0x340 [vrf]<br /> vrf_l3_out+0x5f4/0xe80 [vrf]<br /> __ip_local_out+0x51e/0x7a0<br /> [...]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/v3d: Prevent out of bounds access in performance query extensions<br /> <br /> Check that the number of perfmons userspace is passing in the copy and<br /> reset extensions is not greater than the internal kernel storage where<br /> the ids will be copied into.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> r8169: add tally counter fields added with RTL8125<br /> <br /> RTL8125 added fields to the tally counter, what may result in the chip<br /> dma&amp;#39;ing these new fields to unallocated memory. Therefore make sure<br /> that the allocated memory area is big enough to hold all of the<br /> tally counter values, even if we use only parts of it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: Limit the number of concurrent async COPY operations<br /> <br /> Nothing appears to limit the number of concurrent async COPY<br /> operations that clients can start. In addition, AFAICT each async<br /> COPY can copy an unlimited number of 4MB chunks, so can run for a<br /> long time. Thus IMO async COPY can become a DoS vector.<br /> <br /> Add a restriction mechanism that bounds the number of concurrent<br /> background COPY operations. Start simple and try to be fair -- this<br /> patch implements a per-namespace limit.<br /> <br /> An async COPY request that occurs while this limit is exceeded gets<br /> NFS4ERR_DELAY. The requesting client can choose to send the request<br /> again after a delay or fall back to a traditional read/write style<br /> copy.<br /> <br /> If there is need to make the mechanism more sophisticated, we can<br /> visit that in future patches.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> uprobes: fix kernel info leak via "[uprobes]" vma<br /> <br /> xol_add_vma() maps the uninitialized page allocated by __create_xol_area()<br /> into userspace. On some architectures (x86) this memory is readable even<br /> without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ,<br /> although this doesn&amp;#39;t really matter, debugger can read this memory anyway.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: stmmac: Fix zero-division error when disabling tc cbs<br /> <br /> The commit b8c43360f6e4 ("net: stmmac: No need to calculate speed divider<br /> when offload is disabled") allows the "port_transmit_rate_kbps" to be<br /> set to a value of 0, which is then passed to the "div_s64" function when<br /> tc-cbs is disabled. This leads to a zero-division error.<br /> <br /> When tc-cbs is disabled, the idleslope, sendslope, and credit values the<br /> credit values are not required to be configured. Therefore, adding a return<br /> statement after setting the txQ mode to DCB when tc-cbs is disabled would<br /> prevent a zero-division error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gso: fix udp gso fraglist segmentation after pull from frag_list<br /> <br /> Detect gso fraglist skbs with corrupted geometry (see below) and<br /> pass these to skb_segment instead of skb_segment_list, as the first<br /> can segment them correctly.<br /> <br /> Valid SKB_GSO_FRAGLIST skbs<br /> - consist of two or more segments<br /> - the head_skb holds the protocol headers plus first gso_size<br /> - one or more frag_list skbs hold exactly one segment<br /> - all but the last must be gso_size<br /> <br /> Optional datapath hooks such as NAT and BPF (bpf_skb_pull_data) can<br /> modify these skbs, breaking these invariants.<br /> <br /> In extreme cases they pull all data into skb linear. For UDP, this<br /> causes a NULL ptr deref in __udpv4_gso_segment_list_csum at<br /> udp_hdr(seg-&gt;next)-&gt;dest.<br /> <br /> Detect invalid geometry due to pull, by checking head_skb size.<br /> Don&amp;#39;t just drop, as this may blackhole a destination. Convert to be<br /> able to pass to regular skb_segment.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: venus: fix use after free bug in venus_remove due to race condition<br /> <br /> in venus_probe, core-&gt;work is bound with venus_sys_error_handler, which is<br /> used to handle error. The code use core-&gt;sys_err_done to make sync work.<br /> The core-&gt;work is started in venus_event_notify.<br /> <br /> If we call venus_remove, there might be an unfished work. The possible<br /> sequence is as follows:<br /> <br /> CPU0 CPU1<br /> <br /> |venus_sys_error_handler<br /> venus_remove |<br /> hfi_destroy |<br /> venus_hfi_destroy |<br /> kfree(hdev); |<br /> |hfi_reinit<br /> |venus_hfi_queues_reinit<br /> |//use hdev<br /> <br /> Fix it by canceling the work in venus_remove.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> aoe: fix the potential use-after-free problem in more places<br /> <br /> For fixing CVE-2023-6270, f98364e92662 ("aoe: fix the potential<br /> use-after-free problem in aoecmd_cfg_pkts") makes tx() calling dev_put()<br /> instead of doing in aoecmd_cfg_pkts(). It avoids that the tx() runs<br /> into use-after-free.<br /> <br /> Then Nicolai Stange found more places in aoe have potential use-after-free<br /> problem with tx(). e.g. revalidate(), aoecmd_ata_rw(), resend(), probe()<br /> and aoecmd_cfg_rsp(). Those functions also use aoenet_xmit() to push<br /> packet to tx queue. So they should also use dev_hold() to increase the<br /> refcnt of skb-&gt;dev.<br /> <br /> On the other hand, moving dev_put() to tx() causes that the refcnt of<br /> skb-&gt;dev be reduced to a negative value, because corresponding<br /> dev_hold() are not called in revalidate(), aoecmd_ata_rw(), resend(),<br /> probe(), and aoecmd_cfg_rsp(). This patch fixed this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free<br /> <br /> When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(),<br /> the &amp;#39;ppath&amp;#39; is updated but it is the &amp;#39;path&amp;#39; that is freed, thus potentially<br /> triggering a double-free in the following process:<br /> <br /> ext4_ext_replay_update_ex<br /> ppath = path<br /> ext4_force_split_extent_at(&amp;ppath)<br /> ext4_split_extent_at<br /> ext4_ext_insert_extent<br /> ext4_ext_create_new_leaf<br /> ext4_ext_grow_indepth<br /> ext4_find_extent<br /> if (depth &gt; path[0].p_maxdepth)<br /> kfree(path) ---&gt; path First freed<br /> *orig_path = path = NULL ---&gt; null ppath<br /> kfree(path) ---&gt; path double-free !!!<br /> <br /> So drop the unnecessary ppath and use path directly to avoid this problem.<br /> And use ext4_find_extent() directly to update path, avoiding unnecessary<br /> memory allocation and freeing. Also, propagate the error returned by<br /> ext4_find_extent() instead of using strange error codes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume<br /> <br /> In case there is any sort of clock controller attached to this I2C bus<br /> controller, for example Versaclock or even an AIC32x4 I2C codec, then<br /> an I2C transfer triggered from the clock controller clk_ops .prepare<br /> callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex.<br /> <br /> This is because the clock controller first grabs the prepare_lock mutex<br /> and then performs the prepare operation, including its I2C access. The<br /> I2C access resumes this I2C bus controller via .runtime_resume callback,<br /> which calls clk_prepare_enable(), which attempts to grab the prepare_lock<br /> mutex again and deadlocks.<br /> <br /> Since the clock are already prepared since probe() and unprepared in<br /> remove(), use simple clk_enable()/clk_disable() calls to enable and<br /> disable the clock on runtime suspend and resume, to avoid hitting the<br /> prepare_lock mutex.