Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: prevent out-of-bounds stream writes by validating *pos<br /> <br /> ksmbd_vfs_stream_write() did not validate whether the write offset<br /> (*pos) was within the bounds of the existing stream data length (v_len).<br /> If *pos was greater than or equal to v_len, this could lead to an<br /> out-of-bounds memory write.<br /> <br /> This patch adds a check to ensure *pos is less than v_len before<br /> proceeding. If the condition fails, -EINVAL is returned.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHY<br /> <br /> DSA has 2 kinds of drivers:<br /> <br /> 1. Those who call dsa_switch_suspend() and dsa_switch_resume() from<br /> their device PM ops: qca8k-8xxx, bcm_sf2, microchip ksz<br /> 2. Those who don&amp;#39;t: all others. The above methods should be optional.<br /> <br /> For type 1, dsa_switch_suspend() calls dsa_user_suspend() -&gt; phylink_stop(),<br /> and dsa_switch_resume() calls dsa_user_resume() -&gt; phylink_start().<br /> These seem good candidates for setting mac_managed_pm = true because<br /> that is essentially its definition [1], but that does not seem to be the<br /> biggest problem for now, and is not what this change focuses on.<br /> <br /> Talking strictly about the 2nd category of DSA drivers here (which<br /> do not have MAC managed PM, meaning that for their attached PHYs,<br /> mdio_bus_phy_suspend() and mdio_bus_phy_resume() should run in full),<br /> I have noticed that the following warning from mdio_bus_phy_resume() is<br /> triggered:<br /> <br /> WARN_ON(phydev-&gt;state != PHY_HALTED &amp;&amp; phydev-&gt;state != PHY_READY &amp;&amp;<br /> phydev-&gt;state != PHY_UP);<br /> <br /> because the PHY state machine is running.<br /> <br /> It&amp;#39;s running as a result of a previous dsa_user_open() -&gt; ... -&gt;<br /> phylink_start() -&gt; phy_start() having been initiated by the user.<br /> <br /> The previous mdio_bus_phy_suspend() was supposed to have called<br /> phy_stop_machine(), but it didn&amp;#39;t. So this is why the PHY is in state<br /> PHY_NOLINK by the time mdio_bus_phy_resume() runs.<br /> <br /> mdio_bus_phy_suspend() did not call phy_stop_machine() because for<br /> phylink, the phydev-&gt;adjust_link function pointer is NULL. This seems a<br /> technicality introduced by commit fddd91016d16 ("phylib: fix PAL state<br /> machine restart on resume"). That commit was written before phylink<br /> existed, and was intended to avoid crashing with consumer drivers which<br /> don&amp;#39;t use the PHY state machine - phylink always does, when using a PHY.<br /> But phylink itself has historically not been developed with<br /> suspend/resume in mind, and apparently not tested too much in that<br /> scenario, allowing this bug to exist unnoticed for so long. Plus, prior<br /> to the WARN_ON(), it would have likely been invisible.<br /> <br /> This issue is not in fact restricted to type 2 DSA drivers (according to<br /> the above ad-hoc classification), but can be extrapolated to any MAC<br /> driver with phylink and MDIO-bus-managed PHY PM ops. DSA is just where<br /> the issue was reported. Assuming mac_managed_pm is set correctly, a<br /> quick search indicates the following other drivers might be affected:<br /> <br /> $ grep -Zlr PHYLINK_NETDEV drivers/ | xargs -0 grep -L mac_managed_pm<br /> drivers/net/ethernet/atheros/ag71xx.c<br /> drivers/net/ethernet/microchip/sparx5/sparx5_main.c<br /> drivers/net/ethernet/microchip/lan966x/lan966x_main.c<br /> drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c<br /> drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c<br /> drivers/net/ethernet/freescale/dpaa/dpaa_eth.c<br /> drivers/net/ethernet/freescale/ucc_geth.c<br /> drivers/net/ethernet/freescale/enetc/enetc_pf_common.c<br /> drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c<br /> drivers/net/ethernet/marvell/mvneta.c<br /> drivers/net/ethernet/marvell/prestera/prestera_main.c<br /> drivers/net/ethernet/mediatek/mtk_eth_soc.c<br /> drivers/net/ethernet/altera/altera_tse_main.c<br /> drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c<br /> drivers/net/ethernet/meta/fbnic/fbnic_phylink.c<br /> drivers/net/ethernet/tehuti/tn40_phy.c<br /> drivers/net/ethernet/mscc/ocelot_net.c<br /> <br /> Make the existing conditions dependent on the PHY device having a<br /> phydev-&gt;phy_link_change() implementation equal to the default<br /> phy_link_change() provided by phylib. Otherwise, we implicitly know that<br /> the phydev has the phylink-provided phylink_phy_change() callback, and<br /> when phylink is used, the PHY state machine always needs to be stopped/<br /> started on the suspend/resume path. The code is structured as such that<br /> if phydev-&gt;phy_link_change() is absent, it is a matter of time until the<br /> kernel will crash - no need to further complicate the test.<br /> <br /> Thus, for the situation where the PM is not managed b<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Verify event formats that have "%*p.."<br /> <br /> The trace event verifier checks the formats of trace events to make sure<br /> that they do not point at memory that is not in the trace event itself or<br /> in data that will never be freed. If an event references data that was<br /> allocated when the event triggered and that same data is freed before the<br /> event is read, then the kernel can crash by reading freed memory.<br /> <br /> The verifier runs at boot up (or module load) and scans the print formats<br /> of the events and checks their arguments to make sure that dereferenced<br /> pointers are safe. If the format uses "%*p.." the verifier will ignore it,<br /> and that could be dangerous. Cover this case as well.<br /> <br /> Also add to the sample code a use case of "%*pbl".

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ftrace: Add cond_resched() to ftrace_graph_set_hash()<br /> <br /> When the kernel contains a large number of functions that can be traced,<br /> the loop in ftrace_graph_set_hash() may take a lot of time to execute.<br /> This may trigger the softlockup watchdog.<br /> <br /> Add cond_resched() within the loop to allow the kernel to remain<br /> responsive even when processing a large number of functions.<br /> <br /> This matches the cond_resched() that is used in other locations of the<br /> code that iterates over all functions that can be traced.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: codecs: wcd937x: fix a potential memory leak in wcd937x_soc_codec_probe()<br /> <br /> When snd_soc_dapm_new_controls() or snd_soc_dapm_add_routes() fails,<br /> wcd937x_soc_codec_probe() returns without releasing &amp;#39;wcd937x-&gt;clsh_info&amp;#39;,<br /> which is allocated by wcd_clsh_ctrl_alloc. Add wcd_clsh_ctrl_free()<br /> to prevent potential memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libbpf: Fix accessing BTF.ext core_relo header<br /> <br /> Update btf_ext_parse_info() to ensure the core_relo header is present<br /> before reading its fields. This avoids a potential buffer read overflow<br /> reported by the OSS Fuzz project.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/x86/intel: KVM: Mask PEBS_ENABLE loaded for guest with vCPU&amp;#39;s value.<br /> <br /> When generating the MSR_IA32_PEBS_ENABLE value that will be loaded on<br /> VM-Entry to a KVM guest, mask the value with the vCPU&amp;#39;s desired PEBS_ENABLE<br /> value. Consulting only the host kernel&amp;#39;s host vs. guest masks results in<br /> running the guest with PEBS enabled even when the guest doesn&amp;#39;t want to use<br /> PEBS. Because KVM uses perf events to proxy the guest virtual PMU, simply<br /> looking at exclude_host can&amp;#39;t differentiate between events created by host<br /> userspace, and events created by KVM on behalf of the guest.<br /> <br /> Running the guest with PEBS unexpectedly enabled typically manifests as<br /> crashes due to a near-infinite stream of #PFs. E.g. if the guest hasn&amp;#39;t<br /> written MSR_IA32_DS_AREA, the CPU will hit page faults on address &amp;#39;0&amp;#39; when<br /> trying to record PEBS events.<br /> <br /> The issue is most easily reproduced by running `perf kvm top` from before<br /> commit 7b100989b4f6 ("perf evlist: Remove __evlist__add_default") (after<br /> which, `perf kvm top` effectively stopped using PEBS). The userspace side<br /> of perf creates a guest-only PEBS event, which intel_guest_get_msrs()<br /> misconstrues a guest-*owned* PEBS event.<br /> <br /> Arguably, this is a userspace bug, as enabling PEBS on guest-only events<br /> simply cannot work, and userspace can kill VMs in many other ways (there<br /> is no danger to the host). However, even if this is considered to be bad<br /> userspace behavior, there&amp;#39;s zero downside to perf/KVM restricting PEBS to<br /> guest-owned events.<br /> <br /> Note, commit 854250329c02 ("KVM: x86/pmu: Disable guest PEBS temporarily<br /> in two rare situations") fixed the case where host userspace is profiling<br /> KVM *and* userspace, but missed the case where userspace is profiling only<br /> KVM.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> objtool, media: dib8000: Prevent divide-by-zero in dib8000_set_dds()<br /> <br /> If dib8000_set_dds()&amp;#39;s call to dib8000_read32() returns zero, the result<br /> is a divide-by-zero. Prevent that from happening.<br /> <br /> Fixes the following warning with an UBSAN kernel:<br /> <br /> drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000_tune() falls through to next function dib8096p_cfg_DibRx()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: mtk_eth_soc: fix SER panic with 4GB+ RAM<br /> <br /> If the mtk_poll_rx() function detects the MTK_RESETTING flag, it will<br /> jump to release_desc and refill the high word of the SDP on the 4GB RFB.<br /> Subsequently, mtk_rx_clean will process an incorrect SDP, leading to a<br /> panic.<br /> <br /> Add patch from MediaTek&amp;#39;s SDK to resolve this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: simple-card-utils: Fix pointer check in graph_util_parse_link_direction<br /> <br /> Actually check if the passed pointers are valid, before writing to them.<br /> This also fixes a USBAN warning:<br /> UBSAN: invalid-load in ../sound/soc/fsl/imx-card.c:687:25<br /> load of value 255 is not a valid value for type &amp;#39;_Bool&amp;#39;<br /> <br /> This is because playback_only is uninitialized and is not written to, as<br /> the playback-only property is absent.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/nouveau: Fix WARN_ON in nouveau_fence_context_kill()<br /> <br /> Nouveau is mostly designed in a way that it&amp;#39;s expected that fences only<br /> ever get signaled through nouveau_fence_signal(). However, in at least<br /> one other place, nouveau_fence_done(), can signal fences, too. If that<br /> happens (race) a signaled fence remains in the pending list for a while,<br /> until it gets removed by nouveau_fence_update().<br /> <br /> Should nouveau_fence_context_kill() run in the meantime, this would be<br /> a bug because the function would attempt to set an error code on an<br /> already signaled fence.<br /> <br /> Have nouveau_fence_context_kill() check for a fence being signaled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: errata: Add missing sentinels to Spectre-BHB MIDR arrays<br /> <br /> Commit a5951389e58d ("arm64: errata: Add newer ARM cores to the<br /> spectre_bhb_loop_affected() lists") added some additional CPUs to the<br /> Spectre-BHB workaround, including some new arrays for designs that<br /> require new &amp;#39;k&amp;#39; values for the workaround to be effective.<br /> <br /> Unfortunately, the new arrays omitted the sentinel entry and so<br /> is_midr_in_range_list() will walk off the end when it doesn&amp;#39;t find a<br /> match. With UBSAN enabled, this leads to a crash during boot when<br /> is_midr_in_range_list() is inlined (which was more common prior to<br /> c8c2647e69be ("arm64: Make  _midr_in_range_list() an exported<br /> function")):<br /> <br /> | Internal error: aarch64 BRK: 00000000f2000001 [#1] PREEMPT SMP<br /> | pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> | pc : spectre_bhb_loop_affected+0x28/0x30<br /> | lr : is_spectre_bhb_affected+0x170/0x190<br /> | [...]<br /> | Call trace:<br /> | spectre_bhb_loop_affected+0x28/0x30<br /> | update_cpu_capabilities+0xc0/0x184<br /> | init_cpu_features+0x188/0x1a4<br /> | cpuinfo_store_boot_cpu+0x4c/0x60<br /> | smp_prepare_boot_cpu+0x38/0x54<br /> | start_kernel+0x8c/0x478<br /> | __primary_switched+0xc8/0xd4<br /> | Code: 6b09011f 54000061 52801080 d65f03c0 (d4200020)<br /> | ---[ end trace 0000000000000000 ]---<br /> | Kernel panic - not syncing: aarch64 BRK: Fatal exception<br /> <br /> Add the missing sentinel entries.