Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rcu/kvfree: Fix data-race in __mod_timer / kvfree_call_rcu<br /> <br /> KCSAN reports a data race when access the krcp-&gt;monitor_work.timer.expires<br /> variable in the schedule_delayed_monitor_work() function:<br /> <br /> <br /> BUG: KCSAN: data-race in __mod_timer / kvfree_call_rcu<br /> <br /> read to 0xffff888237d1cce8 of 8 bytes by task 10149 on cpu 1:<br /> schedule_delayed_monitor_work kernel/rcu/tree.c:3520 [inline]<br /> kvfree_call_rcu+0x3b8/0x510 kernel/rcu/tree.c:3839<br /> trie_update_elem+0x47c/0x620 kernel/bpf/lpm_trie.c:441<br /> bpf_map_update_value+0x324/0x350 kernel/bpf/syscall.c:203<br /> generic_map_update_batch+0x401/0x520 kernel/bpf/syscall.c:1849<br /> bpf_map_do_batch+0x28c/0x3f0 kernel/bpf/syscall.c:5143<br /> __sys_bpf+0x2e5/0x7a0<br /> __do_sys_bpf kernel/bpf/syscall.c:5741 [inline]<br /> __se_sys_bpf kernel/bpf/syscall.c:5739 [inline]<br /> __x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5739<br /> x64_sys_call+0x2625/0x2d60 arch/x86/include/generated/asm/syscalls_64.h:322<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xc9/0x1c0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> write to 0xffff888237d1cce8 of 8 bytes by task 56 on cpu 0:<br /> __mod_timer+0x578/0x7f0 kernel/time/timer.c:1173<br /> add_timer_global+0x51/0x70 kernel/time/timer.c:1330<br /> __queue_delayed_work+0x127/0x1a0 kernel/workqueue.c:2523<br /> queue_delayed_work_on+0xdf/0x190 kernel/workqueue.c:2552<br /> queue_delayed_work include/linux/workqueue.h:677 [inline]<br /> schedule_delayed_monitor_work kernel/rcu/tree.c:3525 [inline]<br /> kfree_rcu_monitor+0x5e8/0x660 kernel/rcu/tree.c:3643<br /> process_one_work kernel/workqueue.c:3229 [inline]<br /> process_scheduled_works+0x483/0x9a0 kernel/workqueue.c:3310<br /> worker_thread+0x51d/0x6f0 kernel/workqueue.c:3391<br /> kthread+0x1d1/0x210 kernel/kthread.c:389<br /> ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244<br /> <br /> Reported by Kernel Concurrency Sanitizer on:<br /> CPU: 0 UID: 0 PID: 56 Comm: kworker/u8:4 Not tainted 6.12.0-rc2-syzkaller-00050-g5b7c893ed5ed #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024<br /> Workqueue: events_unbound kfree_rcu_monitor<br /> <br /> <br /> kfree_rcu_monitor() rearms the work if a "krcp" has to be still<br /> offloaded and this is done without holding krcp-&gt;lock, whereas<br /> the kvfree_call_rcu() holds it.<br /> <br /> Fix it by acquiring the "krcp-&gt;lock" for kfree_rcu_monitor() so<br /> both functions do not race anymore.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: qat/qat_4xxx - fix off by one in uof_get_name()<br /> <br /> The fw_objs[] array has "num_objs" elements so the &gt; needs to be &gt;= to<br /> prevent an out of bounds read.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: qat/qat_420xx - fix off by one in uof_get_name()<br /> <br /> This is called from uof_get_name_420xx() where "num_objs" is the<br /> ARRAY_SIZE() of fw_objs[]. The &gt; needs to be &gt;= to prevent an out of<br /> bounds access.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: qcom: geni-se: fix array underflow in geni_se_clk_tbl_get()<br /> <br /> This loop is supposed to break if the frequency returned from<br /> clk_round_rate() is the same as on the previous iteration. However,<br /> that check doesn&amp;#39;t make sense on the first iteration through the loop.<br /> It leads to reading before the start of these-&gt;clk_perf_tbl[] array.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> EDAC/bluefield: Fix potential integer overflow<br /> <br /> The 64-bit argument for the "get DIMM info" SMC call consists of mem_ctrl_idx<br /> left-shifted 16 bits and OR-ed with DIMM index. With mem_ctrl_idx defined as<br /> 32-bits wide the left-shift operation truncates the upper 16 bits of<br /> information during the calculation of the SMC argument.<br /> <br /> The mem_ctrl_idx stack variable must be defined as 64-bits wide to prevent any<br /> potential integer overflow, i.e. loss of data from upper 16 bits.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: ucsi: glink: fix off-by-one in connector_status<br /> <br /> UCSI connector&amp;#39;s indices start from 1 up to 3, PMIC_GLINK_MAX_PORTS.<br /> Correct the condition in the pmic_glink_ucsi_connector_status()<br /> callback, fixing Type-C orientation reporting for the third USB-C<br /> connector.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: tegra194: Move controller cleanups to pex_ep_event_pex_rst_deassert()<br /> <br /> Currently, the endpoint cleanup function dw_pcie_ep_cleanup() and EPF<br /> deinit notify function pci_epc_deinit_notify() are called during the<br /> execution of pex_ep_event_pex_rst_assert() i.e., when the host has asserted<br /> PERST#. But quickly after this step, refclk will also be disabled by the<br /> host.<br /> <br /> All of the tegra194 endpoint SoCs supported as of now depend on the refclk<br /> from the host for keeping the controller operational. Due to this<br /> limitation, any access to the hardware registers in the absence of refclk<br /> will result in a whole endpoint crash. Unfortunately, most of the<br /> controller cleanups require accessing the hardware registers (like eDMA<br /> cleanup performed in dw_pcie_ep_cleanup(), etc...). So these cleanup<br /> functions can cause the crash in the endpoint SoC once host asserts PERST#.<br /> <br /> One way to address this issue is by generating the refclk in the endpoint<br /> itself and not depending on the host. But that is not always possible as<br /> some of the endpoint designs do require the endpoint to consume refclk from<br /> the host.<br /> <br /> Thus, fix this crash by moving the controller cleanups to the start of<br /> the pex_ep_event_pex_rst_deassert() function. This function is called<br /> whenever the host has deasserted PERST# and it is guaranteed that the<br /> refclk would be active at this point. So at the start of this function<br /> (after enabling resources) the controller cleanup can be performed. Once<br /> finished, rest of the code execution for PERST# deassert can continue as<br /> usual.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: qcom-ep: Move controller cleanups to qcom_pcie_perst_deassert()<br /> <br /> Currently, the endpoint cleanup function dw_pcie_ep_cleanup() and EPF<br /> deinit notify function pci_epc_deinit_notify() are called during the<br /> execution of qcom_pcie_perst_assert() i.e., when the host has asserted<br /> PERST#. But quickly after this step, refclk will also be disabled by the<br /> host.<br /> <br /> All of the Qcom endpoint SoCs supported as of now depend on the refclk from<br /> the host for keeping the controller operational. Due to this limitation,<br /> any access to the hardware registers in the absence of refclk will result<br /> in a whole endpoint crash. Unfortunately, most of the controller cleanups<br /> require accessing the hardware registers (like eDMA cleanup performed in<br /> dw_pcie_ep_cleanup(), powering down MHI EPF etc...). So these cleanup<br /> functions are currently causing the crash in the endpoint SoC once host<br /> asserts PERST#.<br /> <br /> One way to address this issue is by generating the refclk in the endpoint<br /> itself and not depending on the host. But that is not always possible as<br /> some of the endpoint designs do require the endpoint to consume refclk from<br /> the host (as I was told by the Qcom engineers).<br /> <br /> Thus, fix this crash by moving the controller cleanups to the start of<br /> the qcom_pcie_perst_deassert() function. qcom_pcie_perst_deassert() is<br /> called whenever the host has deasserted PERST# and it is guaranteed that<br /> the refclk would be active at this point. So at the start of this function<br /> (after enabling resources), the controller cleanup can be performed. Once<br /> finished, rest of the code execution for PERST# deassert can continue as<br /> usual.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb-audio: Fix out of bounds reads when finding clock sources<br /> <br /> The current USB-audio driver code doesn&amp;#39;t check bLength of each<br /> descriptor at traversing for clock descriptors. That is, when a<br /> device provides a bogus descriptor with a shorter bLength, the driver<br /> might hit out-of-bounds reads.<br /> <br /> For addressing it, this patch adds sanity checks to the validator<br /> functions for the clock descriptor traversal. When the descriptor<br /> length is shorter than expected, it&amp;#39;s skipped in the loop.<br /> <br /> For the clock source and clock multiplier descriptors, we can just<br /> check bLength against the sizeof() of each descriptor type.<br /> OTOH, the clock selector descriptor of UAC2 and UAC3 has an array<br /> of bNrInPins elements and two more fields at its tail, hence those<br /> have to be checked in addition to the sizeof() check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> svcrdma: Address an integer overflow<br /> <br /> Dan Carpenter reports:<br /> &gt; Commit 78147ca8b4a9 ("svcrdma: Add a "parsed chunk list" data<br /> &gt; structure") from Jun 22, 2020 (linux-next), leads to the following<br /> &gt; Smatch static checker warning:<br /> &gt;<br /> &gt; net/sunrpc/xprtrdma/svc_rdma_recvfrom.c:498 xdr_check_write_chunk()<br /> &gt; warn: potential user controlled sizeof overflow &amp;#39;segcount * 4 * 4&amp;#39;<br /> &gt;<br /> &gt; net/sunrpc/xprtrdma/svc_rdma_recvfrom.c<br /> &gt; 488 static bool xdr_check_write_chunk(struct svc_rdma_recv_ctxt *rctxt)<br /> &gt; 489 {<br /> &gt; 490 u32 segcount;<br /> &gt; 491 __be32 *p;<br /> &gt; 492<br /> &gt; 493 if (xdr_stream_decode_u32(&amp;rctxt-&gt;rc_stream, &amp;segcount))<br /> &gt; ^^^^^^^^<br /> &gt;<br /> &gt; 494 return false;<br /> &gt; 495<br /> &gt; 496 /* A bogus segcount causes this buffer overflow check to fail. */<br /> &gt; 497 p = xdr_inline_decode(&amp;rctxt-&gt;rc_stream,<br /> &gt; --&gt; 498 segcount * rpcrdma_segment_maxsz * sizeof(*p));<br /> &gt;<br /> &gt;<br /> &gt; segcount is an untrusted u32. On 32bit systems anything &gt;= SIZE_MAX / 16 will<br /> &gt; have an integer overflow and some those values will be accepted by<br /> &gt; xdr_inline_decode().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: clk-apple-nco: Add NULL check in applnco_probe<br /> <br /> Add NULL check in applnco_probe, to handle kernel NULL pointer<br /> dereference error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: fix uninitialized value in ocfs2_file_read_iter()<br /> <br /> Syzbot has reported the following KMSAN splat:<br /> <br /> BUG: KMSAN: uninit-value in ocfs2_file_read_iter+0x9a4/0xf80<br /> ocfs2_file_read_iter+0x9a4/0xf80<br /> __io_read+0x8d4/0x20f0<br /> io_read+0x3e/0xf0<br /> io_issue_sqe+0x42b/0x22c0<br /> io_wq_submit_work+0xaf9/0xdc0<br /> io_worker_handle_work+0xd13/0x2110<br /> io_wq_worker+0x447/0x1410<br /> ret_from_fork+0x6f/0x90<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> Uninit was created at:<br /> __alloc_pages_noprof+0x9a7/0xe00<br /> alloc_pages_mpol_noprof+0x299/0x990<br /> alloc_pages_noprof+0x1bf/0x1e0<br /> allocate_slab+0x33a/0x1250<br /> ___slab_alloc+0x12ef/0x35e0<br /> kmem_cache_alloc_bulk_noprof+0x486/0x1330<br /> __io_alloc_req_refill+0x84/0x560<br /> io_submit_sqes+0x172f/0x2f30<br /> __se_sys_io_uring_enter+0x406/0x41c0<br /> __x64_sys_io_uring_enter+0x11f/0x1a0<br /> x64_sys_call+0x2b54/0x3ba0<br /> do_syscall_64+0xcd/0x1e0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Since an instance of &amp;#39;struct kiocb&amp;#39; may be passed from the block layer<br /> with &amp;#39;private&amp;#39; field uninitialized, introduce &amp;#39;ocfs2_iocb_init_rw_locked()&amp;#39;<br /> and use it from where &amp;#39;ocfs2_dio_end_io()&amp;#39; might take care, i.e. in<br /> &amp;#39;ocfs2_file_read_iter()&amp;#39; and &amp;#39;ocfs2_file_write_iter()&amp;#39;.