CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-53075 – riscv: Prevent a bad reference count on CPU nodes
https://notcve.org/view.php?id=CVE-2024-53075
In the Linux kernel, the following vulnerability has been resolved: riscv: Prevent a bad reference count on CPU nodes When populating cache leaves we previously fetched the CPU device node at the very beginning. But when ACPI is enabled we go through a specific branch which returns early and does not call 'of_node_put' for the node that was acquired. Since we are not using a CPU device node for the ACPI code anyways, we can simply move the initialization of it just passed the ACPI block, and we are guaranteed to have an 'of_node_put' call for the acquired node. This prevents a bad reference count of the CPU device node. Moreover, the previous function did not check for errors when acquiring the device node, so a return -ENOENT has been added for that case. • https://git.kernel.org/stable/c/604f32ea6909b0ebb8ab0bf1ab7dc66ee3dc8955 https://git.kernel.org/stable/c/303846a3dc275e35fbb556d72f1e356ba669e4f8 https://git.kernel.org/stable/c/37233169a6ea912020c572f870075a63293b786a •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-53074 – wifi: iwlwifi: mvm: don't leak a link on AP removal
https://notcve.org/view.php?id=CVE-2024-53074
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't leak a link on AP removal Release the link mapping resource in AP removal. This impacted devices that do not support the MLD API (9260 and down). On those devices, we couldn't start the AP again after the AP has been already started and stopped. • https://git.kernel.org/stable/c/a8b5d4809b503da668966a8187b9872e6c85291c https://git.kernel.org/stable/c/70ddf9ce1894c48dbbf10b0de51a95e4fb3dd376 https://git.kernel.org/stable/c/3ed092997a004d68a3a5b0eeb94e71b69839d0f7 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-53073 – NFSD: Never decrement pending_async_copies on error
https://notcve.org/view.php?id=CVE-2024-53073
In the Linux kernel, the following vulnerability has been resolved: NFSD: Never decrement pending_async_copies on error The error flow in nfsd4_copy() calls cleanup_async_copy(), which already decrements nn->pending_async_copies. • https://git.kernel.org/stable/c/6a488ad7745b8f64625c6d3a24ce7e448e83f11b https://git.kernel.org/stable/c/b4e21431a0db4854b5023cd5af001be557e6c3db https://git.kernel.org/stable/c/1421883aa30c5d26bc3370e2d19cb350f0d5ca28 https://git.kernel.org/stable/c/ed98d26021db0fe62c327aa9f5e57a90bff3fa94 https://git.kernel.org/stable/c/9467c49437e948c541569007cd412d577942e635 https://git.kernel.org/stable/c/949ee5d44d1fd95119b29b3382a933cdc617bf9e https://git.kernel.org/stable/c/fb79d68a36e21960341ccab07d1ac06d93830321 https://git.kernel.org/stable/c/8286f8b622990194207df9ab852e0f87c •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-53072 – platform/x86/amd/pmc: Detect when STB is not available
https://notcve.org/view.php?id=CVE-2024-53072
In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Detect when STB is not available Loading the amd_pmc module as: amd_pmc enable_stb=1 ...can result in the following messages in the kernel ring buffer: amd_pmc AMDI0009:00: SMU cmd failed. err: 0xff ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff WARNING: CPU: 10 PID: 2151 at arch/x86/mm/ioremap.c:217 __ioremap_caller+0x2cd/0x340 Further debugging reveals that this occurs when the requests for S2D_PHYS_ADDR_LOW and S2D_PHYS_ADDR_HIGH return a value of 0, indicating that the STB is inaccessible. To prevent the ioremap warning and provide clarity to the user, handle the invalid address and display an error message. • https://git.kernel.org/stable/c/3d7d407dfb05b257e15cb0c6b056428a4a8c2e5d https://git.kernel.org/stable/c/a50863dd1f92d43c975ab2ecc3476617fe98a66e https://git.kernel.org/stable/c/7a3ed3f125292bc3398e04d10108124250892e3f https://git.kernel.org/stable/c/67ff30e24a0466bdd5be1d0b84385ec3c85fdacd https://git.kernel.org/stable/c/bceec87a73804bb4c33b9a6c96e2d27cd893a801 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-53071 – drm/panthor: Be stricter about IO mapping flags
https://notcve.org/view.php?id=CVE-2024-53071
In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Be stricter about IO mapping flags The current panthor_device_mmap_io() implementation has two issues: 1. For mapping DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET, panthor_device_mmap_io() bails if VM_WRITE is set, but does not clear VM_MAYWRITE. That means userspace can use mprotect() to make the mapping writable later on. This is a classic Linux driver gotcha. I don't think this actually has any impact in practice: When the GPU is powered, writes to the FLUSH_ID seem to be ignored; and when the GPU is not powered, the dummy_latest_flush page provided by the driver is deliberately designed to not do any flushes, so the only thing writing to the dummy_latest_flush could achieve would be to make *more* flushes happen. 2. panthor_device_mmap_io() does not block MAP_PRIVATE mappings (which are mappings without the VM_SHARED flag). MAP_PRIVATE in combination with VM_MAYWRITE indicates that the VMA has copy-on-write semantics, which for VM_PFNMAP are semi-supported but fairly cursed. In particular, in such a mapping, the driver can only install PTEs during mmap() by calling remap_pfn_range() (because remap_pfn_range() wants to **store the physical address of the mapped physical memory into the vm_pgoff of the VMA**); installing PTEs later on with a fault handler (as panthor does) is not supported in private mappings, and so if you try to fault in such a mapping, vmf_insert_pfn_prot() splats when it hits a BUG() check. Fix it by clearing the VM_MAYWRITE flag (userspace writing to the FLUSH_ID doesn't make sense) and requiring VM_SHARED (copy-on-write semantics for the FLUSH_ID don't make sense). Reproducers for both scenarios are in the notes of my patch on the mailing list; I tested that these bugs exist on a Rock 5B machine. Note that I only compile-tested the patch, I haven't tested it; I don't have a working kernel build setup for the test machine yet. Please test it before applying it. • https://git.kernel.org/stable/c/5fe909cae118a757a77afb37174b99436a36d2e2 https://git.kernel.org/stable/c/2604afd65043e8f9d4be036cb1242adf6b5723cf https://git.kernel.org/stable/c/f432a1621f049bb207e78363d9d0e3c6fa2da5db •