CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-41088 – can: mcp251xfd: fix infinite loop when xmit fails
https://notcve.org/view.php?id=CVE-2024-41088
In the Linux kernel, the following vulnerability has been resolved: can: mcp251xfd: fix infinite loop when xmit fails When the mcp251xfd_start_xmit() function fails, the driver stops processing messages, and the interrupt routine does not return, running indefinitely even after killing the running application. Error messages: [ 441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16 [ 441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3). ... and repeat forever. The issue can be triggered when multiple devices share the same SPI interface. And there is concurrent access to the bus. The problem occurs because tx_ring->head increments even if mcp251xfd_start_xmit() fails. Consequently, the driver skips one TX package while still expecting a response in mcp251xfd_handle_tefif_one(). Resolve the issue by starting a workqueue to write the tx obj synchronously if err = -EBUSY. In case of another error, decrement tx_ring->head, remove skb from the echo stack, and drop the message. [mkl: use more imperative wording in patch description] • https://git.kernel.org/stable/c/55e5b97f003e85e66babb55f357627d52081a264 https://git.kernel.org/stable/c/f926c022ebaabf7963bebf89a97201d66978a025 https://git.kernel.org/stable/c/3e72558c1711d524e3150103739ddd06650e291b https://git.kernel.org/stable/c/6c6b4afa59c2fb4d1759235f866d8caed2aa4729 https://git.kernel.org/stable/c/d8fb63e46c884c898a38f061c2330f7729e75510 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-41087 – ata: libata-core: Fix double free on error
https://notcve.org/view.php?id=CVE-2024-41087
In the Linux kernel, the following vulnerability has been resolved: ata: libata-core: Fix double free on error If e.g. the ata_port_alloc() call in ata_host_alloc() fails, we will jump to the err_out label, which will call devres_release_group(). devres_release_group() will trigger a call to ata_host_release(). ata_host_release() calls kfree(host), so executing the kfree(host) in ata_host_alloc() will lead to a double free: kernel BUG at mm/slub.c:553! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:kfree+0x2cf/0x2f0 Code: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da RSP: 0018:ffffc90000f377f0 EFLAGS: 00010246 RAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320 RDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0 RBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000 R10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780 R13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006 FS: 00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? __die_body.cold+0x19/0x27 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? • https://git.kernel.org/stable/c/dafd6c496381c1cd1f5ba9ad953e810bdcc931bc https://git.kernel.org/stable/c/290073b2b557e4dc21ee74a1e403d9ae79e393a2 https://git.kernel.org/stable/c/56f1c7e290cd6c69c948fcd2e2a49e6a637ec38f https://git.kernel.org/stable/c/010de9acbea58fbcbda08e3793d6262086a493fe https://git.kernel.org/stable/c/5dde5f8b790274723640d29a07c5a97d57d62047 https://git.kernel.org/stable/c/702c1edbafb2e6f9d20f6d391273b5be09d366a5 https://git.kernel.org/stable/c/062e256516d7db5e7dcdef117f52025cd5c456e3 https://git.kernel.org/stable/c/8106da4d88bbaed809e023cc8014b7662 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-41085 – cxl/mem: Fix no cxl_nvd during pmem region auto-assembling
https://notcve.org/view.php?id=CVE-2024-41085
In the Linux kernel, the following vulnerability has been resolved: cxl/mem: Fix no cxl_nvd during pmem region auto-assembling When CXL subsystem is auto-assembling a pmem region during cxl endpoint port probing, always hit below calltrace. BUG: kernel NULL pointer dereference, address: 0000000000000078 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page RIP: 0010:cxl_pmem_region_probe+0x22e/0x360 [cxl_pmem] Call Trace: <TASK> ? __die+0x24/0x70 ? page_fault_oops+0x82/0x160 ? do_user_addr_fault+0x65/0x6b0 ? exc_page_fault+0x7d/0x170 ? • https://git.kernel.org/stable/c/f17b558d6663101f876a1d9cbbad3de0c8f4ce4d https://git.kernel.org/stable/c/1d064e4fbebcf5b18dc10c1f3973487eb163b600 https://git.kernel.org/stable/c/84ec985944ef34a34a1605b93ce401aa8737af96 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-41084 – cxl/region: Avoid null pointer dereference in region lookup
https://notcve.org/view.php?id=CVE-2024-41084
In the Linux kernel, the following vulnerability has been resolved: cxl/region: Avoid null pointer dereference in region lookup cxl_dpa_to_region() looks up a region based on a memdev and DPA. It wrongly assumes an endpoint found mapping the DPA is also of a fully assembled region. When not true it leads to a null pointer dereference looking up the region name. This appears during testing of region lookup after a failure to assemble a BIOS defined region or if the lookup raced with the assembly of the BIOS defined region. Failure to clean up BIOS defined regions that fail assembly is an issue in itself and a fix to that problem will alleviate some of the impact. It will not alleviate the race condition so let's harden this path. The behavior change is that the kernel oops due to a null pointer dereference is replaced with a dev_dbg() message noting that an endpoint was mapped. Additional comments are added so that future users of this function can more clearly understand what it provides. • https://git.kernel.org/stable/c/0a105ab28a4de44eb738ce64e9ac74946aa5133b https://git.kernel.org/stable/c/a9e099e29e925f8b31cfe53e8a786b9796f8e453 https://git.kernel.org/stable/c/b8a40a6dbfb0150c1081384caa9bbe28ce5d5060 https://git.kernel.org/stable/c/285f2a08841432fc3e498b1cd00cce5216cdf189 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-41082 – nvme-fabrics: use reserved tag for reg read/write command
https://notcve.org/view.php?id=CVE-2024-41082
In the Linux kernel, the following vulnerability has been resolved: nvme-fabrics: use reserved tag for reg read/write command In some scenarios, if too many commands are issued by nvme command in the same time by user tasks, this may exhaust all tags of admin_q. If a reset (nvme reset or IO timeout) occurs before these commands finish, reconnect routine may fail to update nvme regs due to insufficient tags, which will cause kernel hang forever. In order to workaround this issue, maybe we can let reg_read32()/reg_read64()/reg_write32() use reserved tags. This maybe safe for nvmf: 1. For the disable ctrl path, we will not issue connect command 2. • https://git.kernel.org/stable/c/165da9c67a26f08c9b956c15d701da7690f45bcb https://git.kernel.org/stable/c/7dc3bfcb4c9cc58970fff6aaa48172cb224d85aa •