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/8286f8b622990194207df9ab852e0f87c60d35e9 •
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 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-53070 – usb: dwc3: fix fault at system suspend if device was already runtime suspended
https://notcve.org/view.php?id=CVE-2024-53070
In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: fix fault at system suspend if device was already runtime suspended If the device was already runtime suspended then during system suspend we cannot access the device registers else it will crash. Also we cannot access any registers after dwc3_core_exit() on some platforms so move the dwc3_enable_susphy() call to the top. • https://git.kernel.org/stable/c/073530898ebf44a9418434e899cfa9ca86945333 https://git.kernel.org/stable/c/85ca88f93162acb94dbcb26d0ee2b145864d14a1 https://git.kernel.org/stable/c/4fad7370086797afe6471493e3a5f36add8c48a7 https://git.kernel.org/stable/c/a690a9e38e6ba819789074388de7cff06425ef5b https://git.kernel.org/stable/c/d9e65d461a9de037e7c9d584776d025cfce6d86d https://git.kernel.org/stable/c/562804b1561cc248cc37746a1c96c83cab1d7209 https://git.kernel.org/stable/c/4abc5ee334fe4aba50461c45fdaaa4c5e5c57789 https://git.kernel.org/stable/c/06b98197b69e2f2af9cb1991ee0b1c876 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-53069 – firmware: qcom: scm: fix a NULL-pointer dereference
https://notcve.org/view.php?id=CVE-2024-53069
In the Linux kernel, the following vulnerability has been resolved: firmware: qcom: scm: fix a NULL-pointer dereference Some SCM calls can be invoked with __scm being NULL (the driver may not have been and will not be probed as there's no SCM entry in device-tree). Make sure we don't dereference a NULL pointer. • https://git.kernel.org/stable/c/449d0d84bcd8246b508d07995326d13c54488b8c https://git.kernel.org/stable/c/3d36e2b1d803f0d1cc674115d295a8f20ddb9268 https://git.kernel.org/stable/c/ca61d6836e6f4442a77762e1074d2706a2a6e578 •