CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-46714 – drm/amd/display: Skip wbscl_set_scaler_filter if filter is null
https://notcve.org/view.php?id=CVE-2024-46714
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Skip wbscl_set_scaler_filter if filter is null Callers can pass null in filter (i.e. from returned from the function wbscl_get_filter_coeffs_16p) and a null check is added to ensure that is not the case. This fixes 4 NULL_RETURNS issues reported by Coverity. • https://git.kernel.org/stable/c/0364f1f17a86d89dc39040beea4f099e60189f1b https://git.kernel.org/stable/c/c083c8be6bdd046049884bec076660d4ec9a19ca https://git.kernel.org/stable/c/6d94c05a13fadd80c3e732f14c83b2632ebfaa50 https://git.kernel.org/stable/c/1726914cb17cedab233820d26b86764dc08857b4 https://git.kernel.org/stable/c/e3a95f29647ae45d1ec9541cd7df64f40bf2120a https://git.kernel.org/stable/c/54834585e91cab13e9f82d3a811deb212a4df786 https://git.kernel.org/stable/c/c4d31653c03b90e51515b1380115d1aedad925dd •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-46713 – perf/aux: Fix AUX buffer serialization
https://notcve.org/view.php?id=CVE-2024-46713
In the Linux kernel, the following vulnerability has been resolved: perf/aux: Fix AUX buffer serialization Ole reported that event->mmap_mutex is strictly insufficient to serialize the AUX buffer, add a per RB mutex to fully serialize it. Note that in the lock order comment the perf_event::mmap_mutex order was already wrong, that is, it nesting under mmap_lock is not new with this patch. • https://git.kernel.org/stable/c/45bfb2e50471abbbfd83d40d28c986078b0d24ff https://git.kernel.org/stable/c/7882923f1cb88dc1a17f2bf0c81b1fc80d44db82 https://git.kernel.org/stable/c/52d13d224fdf1299c8b642807fa1ea14d693f5ff https://git.kernel.org/stable/c/9dc7ad2b67772cfb94ceb3b0c9c4023c2463215d https://git.kernel.org/stable/c/c4b69bee3f4ef76809288fe6827bc14d4ae788ef https://git.kernel.org/stable/c/b9b6882e243b653d379abbeaa64a500182aba370 https://git.kernel.org/stable/c/2ab9d830262c132ab5db2f571003d80850d56b2a •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-46707 – KVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3
https://notcve.org/view.php?id=CVE-2024-46707
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3 On a system with a GICv3, if a guest hasn't been configured with GICv3 and that the host is not capable of GICv2 emulation, a write to any of the ICC_*SGI*_EL1 registers is trapped to EL2. We therefore try to emulate the SGI access, only to hit a NULL pointer as no private interrupt is allocated (no GIC, remember?). The obvious fix is to give the guest what it deserves, in the shape of a UNDEF exception. • https://git.kernel.org/stable/c/15818af2f7aa55eff375333cb7689df15d3f24ef https://git.kernel.org/stable/c/96b076e8ee5bc3a1126848c8add0f74bd30dc9d1 https://git.kernel.org/stable/c/94d4fbad01b19ec5eab3d6b50aaec4f9db8b2d8d https://git.kernel.org/stable/c/9d7629bec5c3f80bd0e3bf8103c06a2f7046bd92 https://git.kernel.org/stable/c/2073132f6ed3079369e857a8deb33d11bdd983bc https://git.kernel.org/stable/c/3e6245ebe7ef341639e9a7e402b3ade8ad45a19f •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-46705 – drm/xe: reset mmio mappings with devm
https://notcve.org/view.php?id=CVE-2024-46705
In the Linux kernel, the following vulnerability has been resolved: drm/xe: reset mmio mappings with devm Set our various mmio mappings to NULL. This should make it easier to catch something rogue trying to mess with mmio after device removal. For example, we might unmap everything and then start hitting some mmio address which has already been unmamped by us and then remapped by something else, causing all kinds of carnage. • https://git.kernel.org/stable/c/b1c9fbed3884d3883021d699c7cdf5253a65543a https://git.kernel.org/stable/c/c7117419784f612d59ee565145f722e8b5541fe6 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-46702 – thunderbolt: Mark XDomain as unplugged when router is removed
https://notcve.org/view.php?id=CVE-2024-46702
In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Mark XDomain as unplugged when router is removed I noticed that when we do discrete host router NVM upgrade and it gets hot-removed from the PCIe side as a result of NVM firmware authentication, if there is another host connected with enabled paths we hang in tearing them down. This is due to fact that the Thunderbolt networking driver also tries to cleanup the paths and ends up blocking in tb_disconnect_xdomain_paths() waiting for the domain lock. However, at this point we already cleaned the paths in tb_stop() so there is really no need for tb_disconnect_xdomain_paths() to do that anymore. Furthermore it already checks if the XDomain is unplugged and bails out early so take advantage of that and mark the XDomain as unplugged when we remove the parent router. • https://git.kernel.org/stable/c/747bc154577de6e6af4bc99abfa859b8419bb4d8 https://git.kernel.org/stable/c/23ce6ba3b95488a2b9e9f6d43b340da0c15395dc https://git.kernel.org/stable/c/80ac8d194831eca0c2f4fd862f7925532fda320c https://git.kernel.org/stable/c/18b3ad2a3cc877dd4b16f48d84aa27b78d53bf1d https://git.kernel.org/stable/c/7ca24cf9163c112bb6b580c6fb57c04a1f8b76e1 https://git.kernel.org/stable/c/e2006140ad2e01a02ed0aff49cc2ae3ceeb11f8d •