CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-45014 – s390/boot: Avoid possible physmem_info segment corruption
https://notcve.org/view.php?id=CVE-2024-45014
In the Linux kernel, the following vulnerability has been resolved: s390/boot: Avoid possible physmem_info segment corruption When physical memory for the kernel image is allocated it does not consider extra memory required for offsetting the image start to match it with the lower 20 bits of KASLR virtual base address. That might lead to kernel access beyond its memory range. • https://git.kernel.org/stable/c/693d41f7c938f92d881e6a51525e6c132a186afd https://git.kernel.org/stable/c/a944cba5d57687b747023c3bc074fcf9c790f7df https://git.kernel.org/stable/c/d7fd2941ae9a67423d1c7bee985f240e4686634f •
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! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 7 PID: 930 Comm: (udev-worker) Not tainted 6.9.0-rc3Lyude-Test+ #30 Hardware name: MSI MS-7A39/A320M GAMING PRO (MS-7A39), BIOS 1.I0 01/22/2019 RIP: 0010:sg_init_one+0x85/0xa0 Code: 69 88 32 01 83 e1 03 f6 c3 03 75 20 a8 01 75 1e 48 09 cb 41 89 54 24 08 49 89 1c 24 41 89 6c 24 0c 5b 5d 41 5c e9 7b b9 88 00 <0f> 0b 0f 0b 0f 0b 48 8b 05 5e 46 9a 01 eb b2 66 66 2e 0f 1f 84 00 RSP: 0018:ffffa776017bf6a0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa77600d87000 RCX: 000000000000002b RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffffa77680d87000 RBP: 000000000000e000 R08: 0000000000000000 R09: 0000000000000000 R10: ffff98f4c46aa508 R11: 0000000000000000 R12: ffff98f4c46aa508 R13: ffff98f4c46aa008 R14: ffffa77600d4a000 R15: ffffa77600d4a018 FS: 00007feeb5aae980(0000) GS:ffff98f5c4dc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f22cb9a4520 CR3: 00000001043ba000 CR4: 00000000003506f0 Call Trace: <TASK> ? die+0x36/0x90 ? do_trap+0xdd/0x100 ? sg_init_one+0x85/0xa0 ? • 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. This is verified in xillyusb_setup_base_eps(). On top of that, a XillyUSB device may have additional Bulk OUT endpoints. The information about these endpoints' addresses is deduced from a data structure (the IDT) that the driver fetches from the device while probing it. These endpoints are checked in setup_channels(). A XillyUSB device never has more than one IN endpoint, as all data towards the host is multiplexed in this single Bulk IN endpoint. This is why setup_channels() only checks OUT endpoints. • 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. This will decrement the local_addr_used counter, which is wrong in this case because this counter is linked to 'subflow' endpoints, and here it is a 'signal' endpoint that is being removed. Now, the counter is decremented, only if the ID is being used outside of mptcp_pm_nl_rm_addr_or_subflow(), only for 'subflow' endpoints, and if the ID is not 0 -- local_addr_used is not taking into account these ones. This marking of the ID as being available, and the decrement is done no matter if a subflow using this ID is currently available, because the subflow could have been closed before. • 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 •