CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50004 – drm/amd/display: update DML2 policy EnhancedPrefetchScheduleAccelerationFinal DCN35
https://notcve.org/view.php?id=CVE-2024-50004
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: update DML2 policy EnhancedPrefetchScheduleAccelerationFinal DCN35 [WHY & HOW] Mismatch in DCN35 DML2 cause bw validation failed to acquire unexpected DPP pipe to cause grey screen and system hang. Remove EnhancedPrefetchScheduleAccelerationFinal value override to match HW spec. (cherry picked from commit 9dad21f910fcea2bdcff4af46159101d7f9cd8ba) • https://git.kernel.org/stable/c/945dc25eda88b5d6e30c9686dc619ab981c22d0e https://git.kernel.org/stable/c/4010efc8516899981cc3b57be2d4a2d5d9e50228 https://git.kernel.org/stable/c/0d5e5e8a0aa49ea2163abf128da3b509a6c58286 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-50003 – drm/amd/display: Fix system hang while resume with TBT monitor
https://notcve.org/view.php?id=CVE-2024-50003
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix system hang while resume with TBT monitor [Why] Connected with a Thunderbolt monitor and do the suspend and the system may hang while resume. The TBT monitor HPD will be triggered during the resume procedure and call the drm_client_modeset_probe() while struct drm_connector connector->dev->master is NULL. It will mess up the pipe topology after resume. [How] Skip the TBT monitor HPD during the resume procedure because we currently will probe the connectors after resume by default. (cherry picked from commit 453f86a26945207a16b8f66aaed5962dc2b95b85) • https://git.kernel.org/stable/c/eb9329cd882aa274e92bdb1003bc088433fdee86 https://git.kernel.org/stable/c/722d2d8fc423108597b97efbf165187d16d9aa1e https://git.kernel.org/stable/c/68d603f467a75618eeae5bfe8af32cda47097010 https://git.kernel.org/stable/c/73e441be033d3ed0bdff09b575da3e7d4606ffc9 https://git.kernel.org/stable/c/c2356296f546326f9f06c109e201d42201e1e783 https://git.kernel.org/stable/c/52d4e3fb3d340447dcdac0e14ff21a764f326907 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-50002 – static_call: Handle module init failure correctly in static_call_del_module()
https://notcve.org/view.php?id=CVE-2024-50002
In the Linux kernel, the following vulnerability has been resolved: static_call: Handle module init failure correctly in static_call_del_module() Module insertion invokes static_call_add_module() to initialize the static calls in a module. static_call_add_module() invokes __static_call_init(), which allocates a struct static_call_mod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain. If that allocation fails the function returns with an error code and the module core invokes static_call_del_module() to clean up eventually added static_call_mod entries. This works correctly, when all keys used by the module were converted over to a module chain before the failure. If not then static_call_del_module() causes a #GP as it blindly assumes that key::mods points to a valid struct static_call_mod. The problem is that key::mods is not a individual struct member of struct static_call_key, it's part of a union to save space: union { /* bit 0: 0 = mods, 1 = sites */ unsigned long type; struct static_call_mod *mods; struct static_call_site *sites; }; key::sites is a pointer to the list of built-in usage sites of the static call. The type of the pointer is differentiated by bit 0. A mods pointer has the bit clear, the sites pointer has the bit set. As static_call_del_module() blidly assumes that the pointer is a valid static_call_mod type, it fails to check for this failure case and dereferences the pointer to the list of built-in call sites, which is obviously bogus. Cure it by checking whether the key has a sites or a mods pointer. If it's a sites pointer then the key is not to be touched. As the sites are walked in the same order as in __static_call_init() the site walk can be terminated because all subsequent sites have not been touched by the init code due to the error exit. If it was converted before the allocation fail, then the inner loop which searches for a module match will find nothing. A fail in the second allocation in __static_call_init() is harmless and does not require special treatment. • https://git.kernel.org/stable/c/9183c3f9ed710a8edf1a61e8a96d497258d26e08 https://git.kernel.org/stable/c/ed4c8ce0f307f2ab8778aeb40a8866d171e8f128 https://git.kernel.org/stable/c/b566c7d8a2de403ccc9d8a06195e19bbb386d0e4 https://git.kernel.org/stable/c/c0abbbe8c98c077292221ec7e2baa667c9f0974c https://git.kernel.org/stable/c/2b494471797bff3d257e99dc0a7abb0c5ff3b4cd https://git.kernel.org/stable/c/9c48c2b53191bf991361998f5bb97b8f2fc5a89c https://git.kernel.org/stable/c/4b30051c4864234ec57290c3d142db7c88f10d8a •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-50001 – net/mlx5: Fix error path in multi-packet WQE transmit
https://notcve.org/view.php?id=CVE-2024-50001
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix error path in multi-packet WQE transmit Remove the erroneous unmap in case no DMA mapping was established The multi-packet WQE transmit code attempts to obtain a DMA mapping for the skb. This could fail, e.g. under memory pressure, when the IOMMU driver just can't allocate more memory for page tables. While the code tries to handle this in the path below the err_unmap label it erroneously unmaps one entry from the sq's FIFO list of active mappings. Since the current map attempt failed this unmap is removing some random DMA mapping that might still be required. If the PCI function now presents that IOVA, the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI function in error state. The erroneous behavior was seen in a stress-test environment that created memory pressure. • https://git.kernel.org/stable/c/5af75c747e2a868abbf8611494b50ed5e076fca7 https://git.kernel.org/stable/c/ca36d6c1a49b6965c86dd528a73f38bc62d9c625 https://git.kernel.org/stable/c/ce828b347cf1b3c1b12b091d02463c35ce5097f5 https://git.kernel.org/stable/c/fc357e78176945ca7bcacf92ab794b9ccd41b4f4 https://git.kernel.org/stable/c/26fad69b34fcba80d5c7d9e651f628e6ac927754 https://git.kernel.org/stable/c/ecf310aaf256acbc8182189fe0aa1021c3ddef72 https://git.kernel.org/stable/c/8bb8c12fb5e2b1f03d603d493c92941676f109b5 https://git.kernel.org/stable/c/2bcae12c795f32ddfbf8c80d1b5f1d328 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-49997 – net: ethernet: lantiq_etop: fix memory disclosure
https://notcve.org/view.php?id=CVE-2024-49997
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: lantiq_etop: fix memory disclosure When applying padding, the buffer is not zeroed, which results in memory disclosure. The mentioned data is observed on the wire. This patch uses skb_put_padto() to pad Ethernet frames properly. The mentioned function zeroes the expanded buffer. In case the packet cannot be padded it is silently dropped. Statistics are also not incremented. • https://git.kernel.org/stable/c/504d4721ee8e432af4b5f196a08af38bc4dac5fe https://git.kernel.org/stable/c/905f06a34f960676e7dc77bea00f2f8fe18177ad https://git.kernel.org/stable/c/60c068444c20bf9a3e22b65b5f6f3d9edc852931 https://git.kernel.org/stable/c/185df159843d30fb71f821e7ea4368c2a3bfcd36 https://git.kernel.org/stable/c/469856f76f4802c5d7e3d20e343185188de1e2db https://git.kernel.org/stable/c/2bf4c101d7c99483b8b15a0c8f881e3f399f7e18 https://git.kernel.org/stable/c/e66e38d07b31e177ca430758ed97fbc79f27d966 https://git.kernel.org/stable/c/1097bf16501ed5e35358d848b0a94ad28 •