Vulnerabilities

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.

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 /> 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 /> 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 /> 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 /> 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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thermal: testing: Initialize some variables annoteded with _free()<br /> <br /> Variables annotated with __free() need to be initialized if the function<br /> can return before they get updated for the first time or the attempt to<br /> free the memory pointed to by them upon function return may crash the<br /> kernel.<br /> <br /> Fix this issue in some places in the thermal testing code.

A connection hijacking vulnerability exists in some Huawei home routers. Successful exploitation of this vulnerability may cause DoS or information leakage.(Vulnerability ID:HWPSIRT-2023-34408)<br /> <br /> This vulnerability has been assigned a (CVE)ID:CVE-2023-52718