Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: musb: Fix hardware lockup on first Rx endpoint request<br /> <br /> There is a possibility that a request&amp;#39;s callback could be invoked from<br /> usb_ep_queue() (call trace below, supplemented with missing calls):<br /> <br /> req-&gt;complete from usb_gadget_giveback_request<br /> (drivers/usb/gadget/udc/core.c:999)<br /> usb_gadget_giveback_request from musb_g_giveback<br /> (drivers/usb/musb/musb_gadget.c:147)<br /> musb_g_giveback from rxstate<br /> (drivers/usb/musb/musb_gadget.c:784)<br /> rxstate from musb_ep_restart<br /> (drivers/usb/musb/musb_gadget.c:1169)<br /> musb_ep_restart from musb_ep_restart_resume_work<br /> (drivers/usb/musb/musb_gadget.c:1176)<br /> musb_ep_restart_resume_work from musb_queue_resume_work<br /> (drivers/usb/musb/musb_core.c:2279)<br /> musb_queue_resume_work from musb_gadget_queue<br /> (drivers/usb/musb/musb_gadget.c:1241)<br /> musb_gadget_queue from usb_ep_queue<br /> (drivers/usb/gadget/udc/core.c:300)<br /> <br /> According to the docstring of usb_ep_queue(), this should not happen:<br /> <br /> "Note that @req&amp;#39;s -&gt;complete() callback must never be called from within<br /> usb_ep_queue() as that can create deadlock situations."<br /> <br /> In fact, a hardware lockup might occur in the following sequence:<br /> <br /> 1. The gadget is initialized using musb_gadget_enable().<br /> 2. Meanwhile, a packet arrives, and the RXPKTRDY flag is set, raising an<br /> interrupt.<br /> 3. If IRQs are enabled, the interrupt is handled, but musb_g_rx() finds an<br /> empty queue (next_request() returns NULL). The interrupt flag has<br /> already been cleared by the glue layer handler, but the RXPKTRDY flag<br /> remains set.<br /> 4. The first request is enqueued using usb_ep_queue(), leading to the call<br /> of req-&gt;complete(), as shown in the call trace above.<br /> 5. If the callback enables IRQs and another packet is waiting, step (3)<br /> repeats. The request queue is empty because usb_g_giveback() removes the<br /> request before invoking the callback.<br /> 6. The endpoint remains locked up, as the interrupt triggered by hardware<br /> setting the RXPKTRDY flag has been handled, but the flag itself remains<br /> set.<br /> <br /> For this scenario to occur, it is only necessary for IRQs to be enabled at<br /> some point during the complete callback. This happens with the USB Ethernet<br /> gadget, whose rx_complete() callback calls netif_rx(). If called in the<br /> task context, netif_rx() disables the bottom halves (BHs). When the BHs are<br /> re-enabled, IRQs are also enabled to allow soft IRQs to be processed. The<br /> gadget itself is initialized at module load (or at boot if built-in), but<br /> the first request is enqueued when the network interface is brought up,<br /> triggering rx_complete() in the task context via ioctl(). If a packet<br /> arrives while the interface is down, it can prevent the interface from<br /> receiving any further packets from the USB host.<br /> <br /> The situation is quite complicated with many parties involved. This<br /> particular issue can be resolved in several possible ways:<br /> <br /> 1. Ensure that callbacks never enable IRQs. This would be difficult to<br /> enforce, as discovering how netif_rx() interacts with interrupts was<br /> already quite challenging and u_ether is not the only function driver.<br /> Similar "bugs" could be hidden in other drivers as well.<br /> 2. Disable MUSB interrupts in musb_g_giveback() before calling the callback<br /> and re-enable them afterwars (by calling musb_{dis,en}able_interrupts(),<br /> for example). This would ensure that MUSB interrupts are not handled<br /> during the callback, even if IRQs are enabled. In fact, it would allow<br /> IRQs to be enabled when releasing the lock. However, this feels like an<br /> inelegant hack.<br /> 3. Modify the interrupt handler to clear the RXPKTRDY flag if the request<br /> queue is empty. While this approach also feels like a hack, it wastes<br /> CPU time by attempting to handle incoming packets when the software is<br /> not ready to process them.<br /> 4. Flush the Rx FIFO instead of calling rxstate() in musb_ep_restart().<br /> This ensures that the hardware can receive packets when there is at<br /> least one request in the queue. Once I<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport<br /> <br /> Since transport-&gt;sock has been set to NULL during reset transport,<br /> XPRT_SOCK_UPD_TIMEOUT also needs to be cleared. Otherwise, the<br /> xs_tcp_set_socket_timeouts() may be triggered in xs_tcp_send_request()<br /> to dereference the transport-&gt;sock that has been set to NULL.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mailbox: mtk-cmdq: fix wrong use of sizeof in cmdq_get_clocks()<br /> <br /> It should be size of the struct clk_bulk_data, not data pointer pass to<br /> devm_kcalloc().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: mediatek: Check num_codecs is not zero to avoid panic during probe<br /> <br /> Following commit 13f58267cda3 ("ASoC: soc.h: don&amp;#39;t create dummy<br /> Component via COMP_DUMMY()"), COMP_DUMMY() became an array with zero<br /> length, and only gets populated with the dummy struct after the card is<br /> registered. Since the sound card driver&amp;#39;s probe happens before the card<br /> registration, accessing any of the members of a dummy component during<br /> probe will result in undefined behavior.<br /> <br /> This can be observed in the mt8188 and mt8195 machine sound drivers. By<br /> omitting a dai link subnode in the sound card&amp;#39;s node in the Devicetree,<br /> the default uninitialized dummy codec is used, and when its dai_name<br /> pointer gets passed to strcmp() it results in a null pointer dereference<br /> and a kernel panic.<br /> <br /> In addition to that, set_card_codec_info() in the generic helpers file,<br /> mtk-soundcard-driver.c, will populate a dai link with a dummy codec when<br /> a dai link node is present in DT but with no codec property.<br /> <br /> The result is that at probe time, a dummy codec can either be<br /> uninitialized with num_codecs = 0, or be an initialized dummy codec,<br /> with num_codecs = 1 and dai_name = "snd-soc-dummy-dai". In order to<br /> accommodate for both situations, check that num_codecs is not zero<br /> before accessing the codecs&amp;#39; fields but still check for the codec&amp;#39;s dai<br /> name against "snd-soc-dummy-dai" as needed.<br /> <br /> While at it, also drop the check that dai_name is not null in the mt8192<br /> driver, introduced in commit 4d4e1b6319e5 ("ASoC: mediatek: mt8192:<br /> Check existence of dai_name before dereferencing"), as it is actually<br /> redundant given the preceding num_codecs != 0 check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip/riscv-aplic: Prevent crash when MSI domain is missing<br /> <br /> If the APLIC driver is probed before the IMSIC driver, the parent MSI<br /> domain will be missing, which causes a NULL pointer dereference in<br /> msi_create_device_irq_domain().<br /> <br /> Avoid this by deferring probe until the parent MSI domain is available. Use<br /> dev_err_probe() to avoid printing an error message when returning<br /> -EPROBE_DEFER.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vc4: hdmi: Avoid hang with debug registers when suspended<br /> <br /> Trying to read /sys/kernel/debug/dri/1/hdmi1_regs<br /> when the hdmi is disconnected results in a fatal system hang.<br /> <br /> This is due to the pm suspend code disabling the dvp clock.<br /> That is just a gate of the 108MHz clock in DVP_HT_RPI_MISC_CONFIG,<br /> which results in accesses hanging AXI bus.<br /> <br /> Protect against this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_common.c<br /> <br /> Add error pointer check after calling otx2_mbox_get_rsp().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: intel/ipu6: do not handle interrupts when device is disabled<br /> <br /> Some IPU6 devices have shared interrupts. We need to handle properly<br /> case when interrupt is triggered from other device on shared irq line<br /> and IPU6 itself disabled. In such case we get 0xffffffff from<br /> ISR_STATUS register and handle all irq&amp;#39;s cases, for what we are not<br /> not prepared and usually hang the whole system.<br /> <br /> To avoid the issue use pm_runtime_get_if_active() to check if<br /> the device is enabled and prevent suspending it when we handle irq<br /> until the end of irq. Additionally use synchronize_irq() in suspend

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: bcm - add error check in the ahash_hmac_init function<br /> <br /> The ahash_init functions may return fails. The ahash_hmac_init should<br /> not return ok when ahash_init returns error. For an example, ahash_init<br /> will return -ENOMEM when allocation memory is error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/fadump: Move fadump_cma_init to setup_arch() after initmem_init()<br /> <br /> During early init CMA_MIN_ALIGNMENT_BYTES can be PAGE_SIZE,<br /> since pageblock_order is still zero and it gets initialized<br /> later during initmem_init() e.g.<br /> setup_arch() -&gt; initmem_init() -&gt; sparse_init() -&gt; set_pageblock_order()<br /> <br /> One such use case where this causes issue is -<br /> early_setup() -&gt; early_init_devtree() -&gt; fadump_reserve_mem() -&gt; fadump_cma_init()<br /> <br /> This causes CMA memory alignment check to be bypassed in<br /> cma_init_reserved_mem(). Then later cma_activate_area() can hit<br /> a VM_BUG_ON_PAGE(pfn &amp; ((1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/mm/fault: Fix kfence page fault reporting<br /> <br /> copy_from_kernel_nofault() can be called when doing read of /proc/kcore.<br /> /proc/kcore can have some unmapped kfence objects which when read via<br /> copy_from_kernel_nofault() can cause page faults. Since *_nofault()<br /> functions define their own fixup table for handling fault, use that<br /> instead of asking kfence to handle such faults.<br /> <br /> Hence we search the exception tables for the nip which generated the<br /> fault. If there is an entry then we let the fixup table handler handle the<br /> page fault by returning an error from within ___do_page_fault().<br /> <br /> This can be easily triggered if someone tries to do dd from /proc/kcore.<br /> eg. dd if=/proc/kcore of=/dev/null bs=1M<br /> <br /> Some example false negatives:<br /> <br /> ===============================<br /> BUG: KFENCE: invalid read in copy_from_kernel_nofault+0x9c/0x1a0<br /> Invalid read at 0xc0000000fdff0000:<br /> copy_from_kernel_nofault+0x9c/0x1a0<br /> 0xc00000000665f950<br /> read_kcore_iter+0x57c/0xa04<br /> proc_reg_read_iter+0xe4/0x16c<br /> vfs_read+0x320/0x3ec<br /> ksys_read+0x90/0x154<br /> system_call_exception+0x120/0x310<br /> system_call_vectored_common+0x15c/0x2ec<br /> <br /> BUG: KFENCE: use-after-free read in copy_from_kernel_nofault+0x9c/0x1a0<br /> Use-after-free read at 0xc0000000fe050000 (in kfence-#2):<br /> copy_from_kernel_nofault+0x9c/0x1a0<br /> 0xc00000000665f950<br /> read_kcore_iter+0x57c/0xa04<br /> proc_reg_read_iter+0xe4/0x16c<br /> vfs_read+0x320/0x3ec<br /> ksys_read+0x90/0x154<br /> system_call_exception+0x120/0x310<br /> system_call_vectored_common+0x15c/0x2ec