Vulnerabilities

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;.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service()<br /> <br /> I found the following bug in my fuzzer:<br /> <br /> UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath9k/htc_hst.c:26:51<br /> index 255 is out of range for type &amp;#39;htc_endpoint [22]&amp;#39;<br /> CPU: 0 UID: 0 PID: 8 Comm: kworker/0:0 Not tainted 6.11.0-rc6-dirty #14<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> Workqueue: events request_firmware_work_func<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x180/0x1b0<br /> __ubsan_handle_out_of_bounds+0xd4/0x130<br /> htc_issue_send.constprop.0+0x20c/0x230<br /> ? _raw_spin_unlock_irqrestore+0x3c/0x70<br /> ath9k_wmi_cmd+0x41d/0x610<br /> ? mark_held_locks+0x9f/0xe0<br /> ...<br /> <br /> Since this bug has been confirmed to be caused by insufficient verification<br /> of conn_rsp_epid, I think it would be appropriate to add a range check for<br /> conn_rsp_epid to htc_connect_service() to prevent the bug from occurring.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: arm_scpi: Check the DVFS OPP count returned by the firmware<br /> <br /> Fix a kernel crash with the below call trace when the SCPI firmware<br /> returns OPP count of zero.<br /> <br /> dvfs_info.opp_count may be zero on some platforms during the reboot<br /> test, and the kernel will crash after dereferencing the pointer to<br /> kcalloc(info-&gt;count, sizeof(*opp), GFP_KERNEL).<br /> <br /> | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028<br /> | Mem abort info:<br /> | ESR = 0x96000004<br /> | Exception class = DABT (current EL), IL = 32 bits<br /> | SET = 0, FnV = 0<br /> | EA = 0, S1PTW = 0<br /> | Data abort info:<br /> | ISV = 0, ISS = 0x00000004<br /> | CM = 0, WnR = 0<br /> | user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000faefa08c<br /> | [0000000000000028] pgd=0000000000000000<br /> | Internal error: Oops: 96000004 [#1] SMP<br /> | scpi-hwmon: probe of PHYT000D:00 failed with error -110<br /> | Process systemd-udevd (pid: 1701, stack limit = 0x00000000aaede86c)<br /> | CPU: 2 PID: 1701 Comm: systemd-udevd Not tainted 4.19.90+ #1<br /> | Hardware name: PHYTIUM LTD Phytium FT2000/4/Phytium FT2000/4, BIOS<br /> | pstate: 60000005 (nZCv daif -PAN -UAO)<br /> | pc : scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi]<br /> | lr : clk_register+0x438/0x720<br /> | Call trace:<br /> | scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi]<br /> | devm_clk_hw_register+0x50/0xa0<br /> | scpi_clk_ops_init.isra.2+0xa0/0x138 [clk_scpi]<br /> | scpi_clocks_probe+0x528/0x70c [clk_scpi]<br /> | platform_drv_probe+0x58/0xa8<br /> | really_probe+0x260/0x3d0<br /> | driver_probe_device+0x12c/0x148<br /> | device_driver_attach+0x74/0x98<br /> | __driver_attach+0xb4/0xe8<br /> | bus_for_each_dev+0x88/0xe0<br /> | driver_attach+0x30/0x40<br /> | bus_add_driver+0x178/0x2b0<br /> | driver_register+0x64/0x118<br /> | __platform_driver_register+0x54/0x60<br /> | scpi_clocks_driver_init+0x24/0x1000 [clk_scpi]<br /> | do_one_initcall+0x54/0x220<br /> | do_init_module+0x54/0x1c8<br /> | load_module+0x14a4/0x1668<br /> | __se_sys_finit_module+0xf8/0x110<br /> | __arm64_sys_finit_module+0x24/0x30<br /> | el0_svc_common+0x78/0x170<br /> | el0_svc_handler+0x38/0x78<br /> | el0_svc+0x8/0x340<br /> | Code: 937d7c00 a94153f3 a8c27bfd f9400421 (b8606820)<br /> | ---[ end trace 06feb22469d89fa8 ]---<br /> | Kernel panic - not syncing: Fatal exception<br /> | SMP: stopping secondary CPUs<br /> | Kernel Offset: disabled<br /> | CPU features: 0x10,a0002008<br /> | Memory Limit: none

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> exfat: fix out-of-bounds access of directory entries<br /> <br /> In the case of the directory size is greater than or equal to<br /> the cluster size, if start_clu becomes an EOF cluster(an invalid<br /> cluster) due to file system corruption, then the directory entry<br /> where ei-&gt;hint_femp.eidx hint is outside the directory, resulting<br /> in an out-of-bounds access, which may cause further file system<br /> corruption.<br /> <br /> This commit adds a check for start_clu, if it is an invalid cluster,<br /> the file or directory will be treated as empty.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> um: Fix potential integer overflow during physmem setup<br /> <br /> This issue happens when the real map size is greater than LONG_MAX,<br /> which can be easily triggered on UML/i386.