Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2025-37932 State: PUBLISHED Published: 2025-05-20T15:21:57.469Z Last Updated: 2025-11-03T19:57:30.412Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: sch_htb: make htb_qlen_notify() idempotent htb_qlen_notify() always deactivates the HTB class and in fact could trigger a warning if it is already deactivated. Therefore, it is not idempotent and not friendly to its callers, like fq_codel_dequeue(). Let's make it idempotent to ease qdisc_tree_reduce_backlog() callers' life. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/e6b45f4de763b00dc1c55e685e2dd1aaf525d3c1 - https:/
CVE Program Container: References: - https://git.kernel.org/stable/c/e6b45f4de763b00dc1c55e685e2dd1aaf525d3c1 - https://git.kernel.org/stable/c/32ae12ce6a9f6bace186ca7335220ff59b6cc3cd - https://git.kernel.org/stable/c/967955c9e57f8eebfccc298037d4aaf3d42bc1c9 - https://git.kernel.org/stable/c/73cf6af13153d62f9b76eff422eea79dbc70f15e - https://git.kernel.org/stable/c/bbbf5e0f87078b715e7a665d662a2c0e77f044ae - https://git.kernel.org/stable/c/0a188c0e197383683fd093ab1ea6ce9a5869a6ea - https://git.kernel.org/stable/c/a61f1b5921761fbaf166231418bc1db301e5bf59 - https://git.kernel.org/stable/c/5ba8b837b522d7051ef81bacf3d95383ff8edce5
CVE ID: CVE-2025-37933 State: PUBLISHED Published: 2025-05-20T15:21:58.169Z Last Updated: 2025-05-26T05:24:01.206Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: octeon_ep: Fix host hang issue during device reboot When the host loses heartbeat messages from the device, the driver calls the device-specific ndo_stop function, which frees the resources. If the driver is unloaded in this scenario, it calls ndo_stop again, attempting to free resources that have already been freed, leading to a host hang issue. To resolve this, dev_close should be called instead of the device-specific stop function.dev_close internally calls ndo_stop
esolve this, dev_close should be called instead of the device-specific stop function.dev_close internally calls ndo_stop to stop the network interface and performs additional cleanup tasks. During the driver unload process, if the device is already down, ndo_stop is not called. References: - https://git.kernel.org/stable/c/7e1ca1bed3f66e00377f7d2147be390144924276 - https://git.kernel.org/stable/c/c8d788f800f83b94d9db8b3dacc1d26be38a6ef4 - https://git.kernel.org/stable/c/6d1052423518e7d0aece9af5e77bbc324face8f1 - https://git.kernel.org/stable/c/34f42736b325287a7b2ce37e415838f539767bda
CVE ID: CVE-2025-37934 State: PUBLISHED Published: 2025-05-20T15:21:58.770Z Last Updated: 2025-05-26T05:24:02.785Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: simple-card-utils: Fix pointer check in graph_util_parse_link_direction Actually check if the passed pointers are valid, before writing to them. This also fixes a USBAN warning: UBSAN: invalid-load in ../sound/soc/fsl/imx-card.c:687:25 load of value 255 is not a valid value for type '_Bool' This is because playback_only is uninitialized and is not written to, as the playback-only property is absent. References: - https://git.kernel.org/stable/c/b41a49d5435e0f76da
ot written to, as the playback-only property is absent. References: - https://git.kernel.org/stable/c/b41a49d5435e0f76da320f231b7252800e8f736f - https://git.kernel.org/stable/c/9b5b3088c4d1752253491705919bd7d067964288 - https://git.kernel.org/stable/c/3cc393d2232ec770b5f79bf0673d67702a3536c3
CVE ID: CVE-2025-37935 State: PUBLISHED Published: 2025-05-20T15:21:59.381Z Last Updated: 2025-05-26T05:24:04.101Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: ethernet: mtk_eth_soc: fix SER panic with 4GB+ RAM If the mtk_poll_rx() function detects the MTK_RESETTING flag, it will jump to release_desc and refill the high word of the SDP on the 4GB RFB. Subsequently, mtk_rx_clean will process an incorrect SDP, leading to a panic. Add patch from MediaTek's SDK to resolve this. References: - https://git.kernel.org/stable/c/cb625f783f70dc6614f03612b8e64ad99cb0a13c - https://git.kernel.org/stable/c/317013d1ad13524be02d60b9e98f
nel.org/stable/c/cb625f783f70dc6614f03612b8e64ad99cb0a13c - https://git.kernel.org/stable/c/317013d1ad13524be02d60b9e98f08fbd13f8c14 - https://git.kernel.org/stable/c/67619cf69dec5d1d7792808dfa548616742dd51d - https://git.kernel.org/stable/c/6e0490fc36cdac696f96e57b61d93b9ae32e0f4c
CVE ID: CVE-2025-37936 State: PUBLISHED Published: 2025-05-20T15:22:00.557Z Last Updated: 2025-11-03T19:57:31.811Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: KVM: Mask PEBS_ENABLE loaded for guest with vCPU's value. When generating the MSR_IA32_PEBS_ENABLE value that will be loaded on VM-Entry to a KVM guest, mask the value with the vCPU's desired PEBS_ENABLE value. Consulting only the host kernel's host vs. guest masks results in running the guest with PEBS enabled even when the guest doesn't want to use PEBS. Because KVM uses perf events to proxy the guest virtual PMU, simply looking at exclude_host can't
n't want to use PEBS. Because KVM uses perf events to proxy the guest virtual PMU, simply looking at exclude_host can't differentiate between events created by host userspace, and events created by KVM on behalf of the guest. Running the guest with PEBS unexpectedly enabled typically manifests as crashes due to a near-infinite stream of #PFs. E.g. if the guest hasn't written MSR_IA32_DS_AREA, the CPU will hit page faults on address '0' when trying to record PEBS events. The issue is most easily reproduced by running `perf kvm top` from before commit 7b100989b4f6 ("perf evlist: Remove __evlist__add_default") (after which, `perf kvm top` effectively stopped using PEBS). The userspace side of p
st: Remove __evlist__add_default") (after which, `perf kvm top` effectively stopped using PEBS). The userspace side of perf creates a guest-only PEBS event, which intel_guest_get_msrs() misconstrues a guest-*owned* PEBS event. Arguably, this is a userspace bug, as enabling PEBS on guest-only events simply cannot work, and userspace can kill VMs in many other ways (there is no danger to the host). However, even if this is considered to be bad userspace behavior, there's zero downside to perf/KVM restricting PEBS to guest-owned events. Note, commit 854250329c02 ("KVM: x86/pmu: Disable guest PEBS temporarily in two rare situations") fixed the case where host userspace is profiling KVM *and* use
: Disable guest PEBS temporarily in two rare situations") fixed the case where host userspace is profiling KVM *and* userspace, but missed the case where userspace is profiling only KVM. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/160153cf9e4aa875ad086cc094ce34aac8e13d63 - https://git.kernel.org/stable/c/34b6fa11431aef71045ae5a00d90a7d630597eda - https://git.kernel.org/stable/c/44ee0afc9d1e7a7c1932698de01362ed80cfc4b5 - https://git.kernel.org/stable/c/86aa62895fc2fb7ab09d7ca40fae8ad09841f66b - https://git.kernel.org/stable/c/58f6217e5d0132a9f14e401e62796916aa055c1b
CVE ID: CVE-2025-37937 State: PUBLISHED Published: 2025-05-20T15:34:39.322Z Last Updated: 2025-11-03T19:57:33.187Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: objtool, media: dib8000: Prevent divide-by-zero in dib8000_set_dds() If dib8000_set_dds()'s call to dib8000_read32() returns zero, the result is a divide-by-zero. Prevent that from happening. Fixes the following warning with an UBSAN kernel: drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000_tune() falls through to next function dib8096p_cfg_DibRx() Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/536f7f3595
_cfg_DibRx() Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/536f7f3595ef8187cfa9ea50d7d24fcf4e84e166 - https://git.kernel.org/stable/c/976a85782246a29ba0f6d411a7a4f524cb9ea987 - https://git.kernel.org/stable/c/9b76b198cf209797abcb1314c18ddeb90fe0827b - https://git.kernel.org/stable/c/b9249da6b0ed56269d4f21850df8e5b35dab50bd - https://git.kernel.org/stable/c/75b42dfe87657ede3da3f279bd6b1b16d69af954 - https://git.kernel.org/stable/c/cd80277f652138d2619f149f86ae6d17bce721d1 - https://git.kernel.org/stable/c/c8430e72b99936c206b37a8e2daebb3f8df7f2d8 - https://git.kernel.org/stable/c/6cfe46036b163e5a0f07c6b705b518148e1a8b2f - https://git.kernel.org
7a8e2daebb3f8df7f2d8 - https://git.kernel.org/stable/c/6cfe46036b163e5a0f07c6b705b518148e1a8b2f - https://git.kernel.org/stable/c/e63d465f59011dede0a0f1d21718b59a64c3ff5c
CVE ID: CVE-2025-37938 State: PUBLISHED Published: 2025-05-20T15:34:40.509Z Last Updated: 2025-11-03T19:57:34.583Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tracing: Verify event formats that have "%*p.." The trace event verifier checks the formats of trace events to make sure that they do not point at memory that is not in the trace event itself or in data that will never be freed. If an event references data that was allocated when the event triggered and that same data is freed before the event is read, then the kernel can crash by reading freed memory. The verifier runs at boot up (or module load) and scans the print f
, then the kernel can crash by reading freed memory. The verifier runs at boot up (or module load) and scans the print formats of the events and checks their arguments to make sure that dereferenced pointers are safe. If the format uses "%*p.." the verifier will ignore it, and that could be dangerous. Cover this case as well. Also add to the sample code a use case of "%*pbl". Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/6854c87ac823181c810f8c07489ba543260c0023 - https://git.kernel.org/stable/c/4d11fac941d83509be4e6a21038281d6d96da50c - https://git.kernel.org/stable/c/03127354027508d076073b020d3070990fd6a958 - https://git.kernel.org/stable/c
1d6d96da50c - https://git.kernel.org/stable/c/03127354027508d076073b020d3070990fd6a958 - https://git.kernel.org/stable/c/04b80d45ecfaf780981d6582899e3ab205e4aa08 - https://git.kernel.org/stable/c/c7204fd1758c0caf1938e8a59809a1fdf28a8114 - https://git.kernel.org/stable/c/ea8d7647f9ddf1f81e2027ed305299797299aa03
CVE ID: CVE-2025-37939 State: PUBLISHED Published: 2025-05-20T15:34:41.511Z Last Updated: 2025-05-26T05:24:09.065Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: libbpf: Fix accessing BTF.ext core_relo header Update btf_ext_parse_info() to ensure the core_relo header is present before reading its fields. This avoids a potential buffer read overflow reported by the OSS Fuzz project. References: - https://git.kernel.org/stable/c/d529411ec44535308c5d59cbeff74be6fe14b479 - https://git.kernel.org/stable/c/3a67f60f0a8be10cea7a884a1a00e9feb6645657 - https://git.kernel.org/stable/c/0a7c2a84359612e54328aa52030eb202093da6e2
CVE ID: CVE-2025-37940 State: PUBLISHED Published: 2025-05-20T15:58:17.634Z Last Updated: 2025-11-03T19:57:35.970Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ftrace: Add cond_resched() to ftrace_graph_set_hash() When the kernel contains a large number of functions that can be traced, the loop in ftrace_graph_set_hash() may take a lot of time to execute. This may trigger the softlockup watchdog. Add cond_resched() within the loop to allow the kernel to remain responsive even when processing a large number of functions. This matches the cond_resched() that is used in other locations of the code that iterates over all function
f functions. This matches the cond_resched() that is used in other locations of the code that iterates over all functions that can be traced. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/e5b4ae6f01d4a510d5725eca7254519a1093920d - https://git.kernel.org/stable/c/618655d54c5f8af5d57b77491d08c0f0ff77d114 - https://git.kernel.org/stable/c/dd38803c9088b848c6b56f4f6d7efc4497bfde61 - https://git.kernel.org/stable/c/8dd7d7280357596ba63dfdb4c1725d9dd24bd42a - https://git.kernel.org/stable/c/5d336ac215e5c76e43ef4bca9ba699835e53e2fd - https://git.kernel.org/stable/c/1fce9574b9d515bcb8a75379a8053e18602424e3 - https://git.kernel.org/stable/c/4429535acab
- https://git.kernel.org/stable/c/1fce9574b9d515bcb8a75379a8053e18602424e3 - https://git.kernel.org/stable/c/4429535acab750d963fdc3dfcc9e0eee42f4d599 - https://git.kernel.org/stable/c/72be43ff061a889c6ee648a330a42486cafa15a6 - https://git.kernel.org/stable/c/42ea22e754ba4f2b86f8760ca27f6f71da2d982c
CVE ID: CVE-2025-37941 State: PUBLISHED Published: 2025-05-20T15:58:18.275Z Last Updated: 2025-05-26T05:24:11.521Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: wcd937x: fix a potential memory leak in wcd937x_soc_codec_probe() When snd_soc_dapm_new_controls() or snd_soc_dapm_add_routes() fails, wcd937x_soc_codec_probe() returns without releasing 'wcd937x->clsh_info', which is allocated by wcd_clsh_ctrl_alloc. Add wcd_clsh_ctrl_free() to prevent potential memory leak. References: - https://git.kernel.org/stable/c/acadb2e2b3c5b9977a843a3a94fece9bdcf6aea1 - https://git.kernel.org/stable/c/b573e04116fd33b9143fa276bba
rnel.org/stable/c/acadb2e2b3c5b9977a843a3a94fece9bdcf6aea1 - https://git.kernel.org/stable/c/b573e04116fd33b9143fa276bbab2f0afad0a1ae - https://git.kernel.org/stable/c/aafb5325aca3e806b3ea3707402189263473d257 - https://git.kernel.org/stable/c/3e330acf4efd63876d673c046cd073a1d4ed57a8
CVE ID: CVE-2025-37942 State: PUBLISHED Published: 2025-05-20T15:58:18.935Z Last Updated: 2025-05-26T05:24:12.771Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: HID: pidff: Make sure to fetch pool before checking SIMULTANEOUS_MAX As noted by Anssi some 20 years ago, pool report is sometimes messed up. This worked fine on many devices but casued oops on VRS DirectForce PRO. Here, we're making sure pool report is refetched before trying to access any of it's fields. While loop was replaced with a for loop + exit conditions were moved aroud to decrease the possibility of creating an infinite loop scenario. References: - https://g
t conditions were moved aroud to decrease the possibility of creating an infinite loop scenario. References: - https://git.kernel.org/stable/c/211861869766a7bb7c72158aee0140ec67e182a7 - https://git.kernel.org/stable/c/344d903be8b5c0733ed0f4bc5be34b4a26d905c8 - https://git.kernel.org/stable/c/a6f5d30a5c7713238c5c65c98ad95dacb73688d5 - https://git.kernel.org/stable/c/1f650dcec32d22deb1d6db12300a2b98483099a9
CVE ID: CVE-2025-37943 State: PUBLISHED Published: 2025-05-20T15:58:19.607Z Last Updated: 2025-05-26T05:24:13.928Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix invalid data access in ath12k_dp_rx_h_undecap_nwifi In certain cases, hardware might provide packets with a length greater than the maximum native Wi-Fi header length. This can lead to accessing and modifying fields in the header within the ath12k_dp_rx_h_undecap_nwifi function for DP_RX_DECAP_TYPE_NATIVE_WIFI decap type and potentially resulting in invalid data access and memory corruption. Add a sanity check before processing the SKB to prevent inva
lly resulting in invalid data access and memory corruption. Add a sanity check before processing the SKB to prevent invalid data access in the undecap native Wi-Fi function for the DP_RX_DECAP_TYPE_NATIVE_WIFI decap type. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 References: - https://git.kernel.org/stable/c/7f1d986da5c6abb75ffe4d0d325fc9b341c41a1c - https://git.kernel.org/stable/c/3abe15e756481c45f6acba3d476cb3ca4afc3b61 - https://git.kernel.org/stable/c/6ee653194ddb83674913fd2727b8ecfae0597ade - https://git.kernel.org/stable/c/50be1fb76556e80af9f5da80f28168b6c71bce58 - https://git.kernel.org/stable/c/9a0dddfb30f120db3851627935851d262e4e7acb
CVE ID: CVE-2025-37944 State: PUBLISHED Published: 2025-05-20T15:58:20.211Z Last Updated: 2025-05-26T05:24:15.108Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix invalid entry fetch in ath12k_dp_mon_srng_process Currently, ath12k_dp_mon_srng_process uses ath12k_hal_srng_src_get_next_entry to fetch the next entry from the destination ring. This is incorrect because ath12k_hal_srng_src_get_next_entry is intended for source rings, not destination rings. This leads to invalid entry fetches, causing potential data corruption or crashes due to accessing incorrect memory locations. This happens because the source rin
ng potential data corruption or crashes due to accessing incorrect memory locations. This happens because the source ring and destination ring have different handling mechanisms and using the wrong function results in incorrect pointer arithmetic and ring management. To fix this issue, replace the call to ath12k_hal_srng_src_get_next_entry with ath12k_hal_srng_dst_get_next_entry in ath12k_dp_mon_srng_process. This ensures that the correct function is used for fetching entries from the destination ring, preventing invalid memory accesses. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Refere
E.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 References: - https://git.kernel.org/stable/c/2c512f2eadabb1e80816116894ffaf7d802a944e - https://git.kernel.org/stable/c/ab7edf42ce800eb34d2f73dd7271b826661a06a5 - https://git.kernel.org/stable/c/b6a3b2b2cead103089d3bb7a57d8209bdfa5399d - https://git.kernel.org/stable/c/298f0aea5cb32b5038f991f5db201a0fcbb9a31b - https://git.kernel.org/stable/c/63fdc4509bcf483e79548de6bc08bf3c8e504bb3
CVE ID: CVE-2025-37945 State: PUBLISHED Published: 2025-05-20T15:58:20.841Z Last Updated: 2025-05-26T05:24:16.339Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHY DSA has 2 kinds of drivers: 1. Those who call dsa_switch_suspend() and dsa_switch_resume() from their device PM ops: qca8k-8xxx, bcm_sf2, microchip ksz 2. Those who don't: all others. The above methods should be optional. For type 1, dsa_switch_suspend() calls dsa_user_suspend() -> phylink_stop(), and dsa_switch_resume() calls dsa_user_resume() -> phylink_start(). These seem good can
ser_suspend() -> phylink_stop(), and dsa_switch_resume() calls dsa_user_resume() -> phylink_start(). These seem good candidates for setting mac_managed_pm = true because that is essentially its definition [1], but that does not seem to be the biggest problem for now, and is not what this change focuses on. Talking strictly about the 2nd category of DSA drivers here (which do not have MAC managed PM, meaning that for their attached PHYs, mdio_bus_phy_suspend() and mdio_bus_phy_resume() should run in full), I have noticed that the following warning from mdio_bus_phy_resume() is triggered: WARN_ON(phydev->state != PHY_HALTED && phydev->state != PHY_READY && phydev->state != PHY_UP); because the
is triggered: WARN_ON(phydev->state != PHY_HALTED && phydev->state != PHY_READY && phydev->state != PHY_UP); because the PHY state machine is running. It's running as a result of a previous dsa_user_open() -> ... -> phylink_start() -> phy_start() having been initiated by the user. The previous mdio_bus_phy_suspend() was supposed to have called phy_stop_machine(), but it didn't. So this is why the PHY is in state PHY_NOLINK by the time mdio_bus_phy_resume() runs. mdio_bus_phy_suspend() did not call phy_stop_machine() because for phylink, the phydev->adjust_link function pointer is NULL. This seems a technicality introduced by commit fddd91016d16 ("phylib: fix PAL state machine restart on resu
ter is NULL. This seems a technicality introduced by commit fddd91016d16 ("phylib: fix PAL state machine restart on resume"). That commit was written before phylink existed, and was intended to avoid crashing with consumer drivers which don't use the PHY state machine - phylink always does, when using a PHY. But phylink itself has historically not been developed with suspend/resume in mind, and apparently not tested too much in that scenario, allowing this bug to exist unnoticed for so long. Plus, prior to the WARN_ON(), it would have likely been invisible. This issue is not in fact restricted to type 2 DSA drivers (according to the above ad-hoc classification), but can be extrapolated to an
t in fact restricted to type 2 DSA drivers (according to the above ad-hoc classification), but can be extrapolated to any MAC driver with phylink and MDIO-bus-managed PHY PM ops. DSA is just where the issue was reported. Assuming mac_managed_pm is set correctly, a quick search indicates the following other drivers might be affected: $ grep -Zlr PHYLINK_NETDEV drivers/ | xargs -0 grep -L mac_managed_pm drivers/net/ethernet/atheros/ag71xx.c drivers/net/ethernet/microchip/sparx5/sparx5_main.c drivers/net/ethernet/microchip/lan966x/lan966x_main.c drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c drivers/net/ethernet/freescale/dpaa/dpaa_eth.c d
dpaa2/dpaa2-mac.c drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c drivers/net/ethernet/freescale/dpaa/dpaa_eth.c drivers/net/ethernet/freescale/ucc_geth.c drivers/net/ethernet/freescale/enetc/enetc_pf_common.c drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c drivers/net/ethernet/marvell/mvneta.c drivers/net/ethernet/marvell/prestera/prestera_main.c drivers/net/ethernet/mediatek/mtk_eth_soc.c drivers/net/ethernet/altera/altera_tse_main.c drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c drivers/net/ethernet/meta/fbnic/fbnic_phylink.c drivers/net/ethernet/tehuti/tn40_phy.c drivers/net/ethernet/mscc/ocelot_net.c Make the existing conditions dependent on the PHY device having a phydev->phy_lin
drivers/net/ethernet/mscc/ocelot_net.c Make the existing conditions dependent on the PHY device having a phydev->phy_link_change() implementation equal to the default phy_link_change() provided by phylib. Otherwise, we implicitly know that the phydev has the phylink-provided phylink_phy_change() callback, and when phylink is used, the PHY state machine always needs to be stopped/ started on the suspend/resume path. The code is structured as such that if phydev->phy_link_change() is absent, it is a matter of time until the kernel will crash - no need to further complicate the test. Thus, for the situation where the PM is not managed b ---truncated--- References: - https://git.kernel.org/stabl
e test. Thus, for the situation where the PM is not managed b ---truncated--- References: - https://git.kernel.org/stable/c/a6ed6f8ec81b8ca7100dcd9e62bdbc0dff1b2259 - https://git.kernel.org/stable/c/54e5d00a8de6c13f6c01a94ed48025e882cd15f7 - https://git.kernel.org/stable/c/bd4037d51d3f6667636a1383e78e48a5b7b60755 - https://git.kernel.org/stable/c/fc75ea20ffb452652f0d4033f38fe88d7cfdae35
CVE ID: CVE-2025-37946 State: PUBLISHED Published: 2025-05-20T16:01:43.162Z Last Updated: 2025-05-26T05:24:17.616Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: s390/pci: Fix duplicate pci_dev_put() in disable_slot() when PF has child VFs With commit bcb5d6c76903 ("s390/pci: introduce lock to synchronize state of zpci_dev's") the code to ignore power off of a PF that has child VFs was changed from a direct return to a goto to the unlock and pci_dev_put() section. The change however left the existing pci_dev_put() untouched resulting in a doubple put. This can subsequently cause a use after free if the struct pci_dev is release