CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-45013 – nvme: move stopping keep-alive into nvme_uninit_ctrl()
https://notcve.org/view.php?id=CVE-2024-45013
In the Linux kernel, the following vulnerability has been resolved: nvme: move stopping keep-alive into nvme_uninit_ctrl() Commit 4733b65d82bd ("nvme: start keep-alive after admin queue setup") moves starting keep-alive from nvme_start_ctrl() into nvme_init_ctrl_finish(), but don't move stopping keep-alive into nvme_uninit_ctrl(), so keep-alive work can be started and keep pending after failing to start controller, finally use-after-free is triggered if nvme host driver is unloaded. This patch fixes kernel panic when running nvme/004 in case that connection failure is triggered, by moving stopping keep-alive into nvme_uninit_ctrl(). This way is reasonable because keep-alive is now started in nvme_init_ctrl_finish(). • https://git.kernel.org/stable/c/3af755a46881c32fecaecfdeaf3a8f0a869deca5 https://git.kernel.org/stable/c/4101af98ab573554c4225e328d506fec2a74bc54 https://git.kernel.org/stable/c/a54a93d0e3599b05856971734e15418ac551a14c •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-45012 – nouveau/firmware: use dma non-coherent allocator
https://notcve.org/view.php?id=CVE-2024-45012
In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: use dma non-coherent allocator Currently, enabling SG_DEBUG in the kernel will cause nouveau to hit a BUG() on startup, when the iommu is enabled: kernel BUG at include/linux/scatterlist.h:187! • https://git.kernel.org/stable/c/2541626cfb794e57ba0575a6920826f591f7ced0 https://git.kernel.org/stable/c/cc29c5546c6a373648363ac49781f1d74b530707 https://git.kernel.org/stable/c/57ca481fca97ca4553e8c85d6a94baf4cb40c40e https://git.kernel.org/stable/c/9b340aeb26d50e9a9ec99599e2a39b035fac978e •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-45011 – char: xillybus: Check USB endpoints when probing device
https://notcve.org/view.php?id=CVE-2024-45011
In the Linux kernel, the following vulnerability has been resolved: char: xillybus: Check USB endpoints when probing device Ensure, as the driver probes the device, that all endpoints that the driver may attempt to access exist and are of the correct type. All XillyUSB devices must have a Bulk IN and Bulk OUT endpoint at address 1. • https://git.kernel.org/stable/c/a53d1202aef122894b6e46116a92174a9123db5d https://git.kernel.org/stable/c/25ee8b2908200fc862c0434e5ad483817d50ceda https://git.kernel.org/stable/c/4267131278f5cc98f8db31d035d64bdbbfe18658 https://git.kernel.org/stable/c/5cff754692ad45d5086b75fef8cc3a99c30a1005 https://git.kernel.org/stable/c/1371d32b95972d39c1e6e4bae8b6d0df1b573731 https://git.kernel.org/stable/c/2374bf7558de915edc6ec8cb10ec3291dfab9594 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-45010 – mptcp: pm: only mark 'subflow' endp as available
https://notcve.org/view.php?id=CVE-2024-45010
In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: only mark 'subflow' endp as available Adding the following warning ... WARN_ON_ONCE(msk->pm.local_addr_used == 0) ... before decrementing the local_addr_used counter helped to find a bug when running the "remove single address" subtest from the mptcp_join.sh selftests. Removing a 'signal' endpoint will trigger the removal of all subflows linked to this endpoint via mptcp_pm_nl_rm_addr_or_subflow() with rm_type == MPTCP_MIB_RMSUBFLOW. • https://git.kernel.org/stable/c/06faa22710342bca5e9c249634199c650799fce6 https://git.kernel.org/stable/c/7fdc870d08960961408a44c569f20f50940e7d4f https://git.kernel.org/stable/c/43cf912b0b0fc7b4fd12cbc735d1f5afb8e1322d https://git.kernel.org/stable/c/9849cfc67383ceb167155186f8f8fe8a896b60b3 https://git.kernel.org/stable/c/322ea3778965da72862cca2a0c50253aacf65fe6 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-45009 – mptcp: pm: only decrement add_addr_accepted for MPJ req
https://notcve.org/view.php?id=CVE-2024-45009
In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: only decrement add_addr_accepted for MPJ req Adding the following warning ... WARN_ON_ONCE(msk->pm.add_addr_accepted == 0) ... before decrementing the add_addr_accepted counter helped to find a bug when running the "remove single subflow" subtest from the mptcp_join.sh selftest. Removing a 'subflow' endpoint will first trigger a RM_ADDR, then the subflow closure. • https://git.kernel.org/stable/c/d0876b2284cf8b34dd214b2d0aa21071c345da59 https://git.kernel.org/stable/c/35b31f5549ede4070566b949781e83495906b43d https://git.kernel.org/stable/c/85b866e4c4e63a1d7afb58f1e24273caad03d0b7 https://git.kernel.org/stable/c/d20bf2c96d7ffd171299b32f562f70e5bf5dc608 https://git.kernel.org/stable/c/2060f1efab370b496c4903b840844ecaff324c3c https://git.kernel.org/stable/c/1c1f721375989579e46741f59523e39ec9b2a9bd •