Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: dts: bcm2711: Fix xHCI power-domain<br /> <br /> During s2idle tests on the Raspberry CM4 the VPU firmware always crashes<br /> on xHCI power-domain resume:<br /> <br /> root@raspberrypi:/sys/power# echo freeze &gt; state<br /> [ 70.724347] xhci_suspend finished<br /> [ 70.727730] xhci_plat_suspend finished<br /> [ 70.755624] bcm2835-power bcm2835-power: Power grafx off<br /> [ 70.761127] USB: Set power to 0<br /> <br /> [ 74.653040] USB: Failed to set power to 1 (-110)<br /> <br /> This seems to be caused because of the mixed usage of<br /> raspberrypi-power and bcm2835-power at the same time. So avoid<br /> the usage of the VPU firmware power-domain driver, which<br /> prevents the VPU crash.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "arm64: dts: qcom: sdm845: Affirm IDR0.CCTW on apps_smmu"<br /> <br /> There are reports that the pagetable walker cache coherency is not a<br /> given across the spectrum of SDM845/850 devices, leading to lock-ups<br /> and resets. It works fine on some devices (like the Dragonboard 845c,<br /> but not so much on the Lenovo Yoga C630).<br /> <br /> This unfortunately looks like a fluke in firmware development, where<br /> likely somewhere in the vast hypervisor stack, a change to accommodate<br /> for this was only introduced after the initial software release (which<br /> often serves as a baseline for products).<br /> <br /> Revert the change to avoid additional guesswork around crashes.<br /> <br /> This reverts commit 6b31a9744b8726c69bb0af290f8475a368a4b805.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Unconditionally save+flush host FPSIMD/SVE/SME state<br /> <br /> There are several problems with the way hyp code lazily saves the host&amp;#39;s<br /> FPSIMD/SVE state, including:<br /> <br /> * Host SVE being discarded unexpectedly due to inconsistent<br /> configuration of TIF_SVE and CPACR_ELx.ZEN. This has been seen to<br /> result in QEMU crashes where SVE is used by memmove(), as reported by<br /> Eric Auger:<br /> <br /> https://issues.redhat.com/browse/RHEL-68997<br /> <br /> * Host SVE state is discarded *after* modification by ptrace, which was an<br /> unintentional ptrace ABI change introduced with lazy discarding of SVE state.<br /> <br /> * The host FPMR value can be discarded when running a non-protected VM,<br /> where FPMR support is not exposed to a VM, and that VM uses<br /> FPSIMD/SVE. In these cases the hyp code does not save the host&amp;#39;s FPMR<br /> before unbinding the host&amp;#39;s FPSIMD/SVE/SME state, leaving a stale<br /> value in memory.<br /> <br /> Avoid these by eagerly saving and "flushing" the host&amp;#39;s FPSIMD/SVE/SME<br /> state when loading a vCPU such that KVM does not need to save any of the<br /> host&amp;#39;s FPSIMD/SVE/SME state. For clarity, fpsimd_kvm_prepare() is<br /> removed and the necessary call to fpsimd_save_and_flush_cpu_state() is<br /> placed in kvm_arch_vcpu_load_fp(). As &amp;#39;fpsimd_state&amp;#39; and &amp;#39;fpmr_ptr&amp;#39;<br /> should not be used, they are set to NULL; all uses of these will be<br /> removed in subsequent patches.<br /> <br /> Historical problems go back at least as far as v5.17, e.g. erroneous<br /> assumptions about TIF_SVE being clear in commit:<br /> <br /> 8383741ab2e773a9 ("KVM: arm64: Get rid of host SVE tracking/saving")<br /> <br /> ... and so this eager save+flush probably needs to be backported to ALL<br /> stable trees.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: qcom: pdr: Fix the potential deadlock<br /> <br /> When some client process A call pdr_add_lookup() to add the look up for<br /> the service and does schedule locator work, later a process B got a new<br /> server packet indicating locator is up and call pdr_locator_new_server()<br /> which eventually sets pdr-&gt;locator_init_complete to true which process A<br /> sees and takes list lock and queries domain list but it will timeout due<br /> to deadlock as the response will queued to the same qmi-&gt;wq and it is<br /> ordered workqueue and process B is not able to complete new server<br /> request work due to deadlock on list lock.<br /> <br /> Fix it by removing the unnecessary list iteration as the list iteration<br /> is already being done inside locator work, so avoid it here and just<br /> call schedule_work() here.<br /> <br /> Process A Process B<br /> <br /> process_scheduled_works()<br /> pdr_add_lookup() qmi_data_ready_work()<br /> process_scheduled_works() pdr_locator_new_server()<br /> pdr-&gt;locator_init_complete=true;<br /> pdr_locator_work()<br /> mutex_lock(&amp;pdr-&gt;list_lock);<br /> <br /> pdr_locate_service() mutex_lock(&amp;pdr-&gt;list_lock);<br /> <br /> pdr_get_domain_list()<br /> pr_err("PDR: %s get domain list<br /> txn wait failed: %d\n",<br /> req-&gt;service_name,<br /> ret);<br /> <br /> Timeout error log due to deadlock:<br /> <br /> "<br /> PDR: tms/servreg get domain list txn wait failed: -110<br /> PDR: service lookup for msm/adsp/sensor_pd:tms/servreg failed: -110<br /> "<br /> <br /> Thanks to Bjorn and Johan for letting me know that this commit also fixes<br /> an audio regression when using the in-kernel pd-mapper as that makes it<br /> easier to hit this race. [1]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: check that dummy regulator has been probed before using it<br /> <br /> Due to asynchronous driver probing there is a chance that the dummy<br /> regulator hasn&amp;#39;t already been probed when first accessing it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: dummy: force synchronous probing<br /> <br /> Sometimes I get a NULL pointer dereference at boot time in kobject_get()<br /> with the following call stack:<br /> <br /> anatop_regulator_probe()<br /> devm_regulator_register()<br /> regulator_register()<br /> regulator_resolve_supply()<br /> kobject_get()<br /> <br /> By placing some extra BUG_ON() statements I could verify that this is<br /> raised because probing of the &amp;#39;dummy&amp;#39; regulator driver is not completed<br /> (&amp;#39;dummy_regulator_rdev&amp;#39; is still NULL).<br /> <br /> In the JTAG debugger I can see that dummy_regulator_probe() and<br /> anatop_regulator_probe() can be run by different kernel threads<br /> (kworker/u4:*). I haven&amp;#39;t further investigated whether this can be<br /> changed or if there are other possibilities to force synchronization<br /> between these two probe routines. On the other hand I don&amp;#39;t expect much<br /> boot time penalty by probing the &amp;#39;dummy&amp;#39; regulator synchronously.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/hns: Fix soft lockup during bt pages loop<br /> <br /> Driver runs a for-loop when allocating bt pages and mapping them with<br /> buffer pages. When a large buffer (e.g. MR over 100GB) is being allocated,<br /> it may require a considerable loop count. This will lead to soft lockup:<br /> <br /> watchdog: BUG: soft lockup - CPU#27 stuck for 22s!<br /> ...<br /> Call trace:<br /> hem_list_alloc_mid_bt+0x124/0x394 [hns_roce_hw_v2]<br /> hns_roce_hem_list_request+0xf8/0x160 [hns_roce_hw_v2]<br /> hns_roce_mtr_create+0x2e4/0x360 [hns_roce_hw_v2]<br /> alloc_mr_pbl+0xd4/0x17c [hns_roce_hw_v2]<br /> hns_roce_reg_user_mr+0xf8/0x190 [hns_roce_hw_v2]<br /> ib_uverbs_reg_mr+0x118/0x290<br /> <br /> watchdog: BUG: soft lockup - CPU#35 stuck for 23s!<br /> ...<br /> Call trace:<br /> hns_roce_hem_list_find_mtt+0x7c/0xb0 [hns_roce_hw_v2]<br /> mtr_map_bufs+0xc4/0x204 [hns_roce_hw_v2]<br /> hns_roce_mtr_create+0x31c/0x3c4 [hns_roce_hw_v2]<br /> alloc_mr_pbl+0xb0/0x160 [hns_roce_hw_v2]<br /> hns_roce_reg_user_mr+0x108/0x1c0 [hns_roce_hw_v2]<br /> ib_uverbs_reg_mr+0x120/0x2bc<br /> <br /> Add a cond_resched() to fix soft lockup during these loops. In order not<br /> to affect the allocation performance of normal-size buffer, set the loop<br /> count of a 100GB MR as the threshold to call cond_resched().

A vulnerability has been identified in Industrial Edge Device Kit - arm64 V1.17 (All versions), Industrial Edge Device Kit - arm64 V1.18 (All versions), Industrial Edge Device Kit - arm64 V1.19 (All versions), Industrial Edge Device Kit - arm64 V1.20 (All versions

A vulnerability has been identified in SENTRON 7KT PAC1260 Data Manager (All versions). Affected devices contain hardcoded credentials for remote access to the device operating system with root privileges. This could allow unauthenticated remote attackers to gain full access to a device, if they are in possession of these credentials and if the ssh service is enabled (e.g., by exploitation of CVE-2024-41793).

A vulnerability has been identified in SENTRON 7KT PAC1260 Data Manager (All versions). The web interface of affected devices is vulnerable to Cross-Site Request Forgery (CSRF) attacks. This could allow an unauthenticated attacker to change arbitrary device settings by tricking a legitimate device administrator to click on a malicious link.

A vulnerability has been identified in SENTRON 7KT PAC1260 Data Manager (All versions). The web interface of affected devices allows to change the login password without knowing the current password. In combination with a prepared CSRF attack (CVE-2024-41795) an unauthenticated attacker could be able to set the password to an attacker-controlled value.

A vulnerability has been identified in SENTRON 7KT PAC1260 Data Manager (All versions). The web interface of affected devices contains a path traversal vulnerability. This could allow an unauthenticated attacker it to access arbitrary files on the device with root privileges.