CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-56687 – usb: musb: Fix hardware lockup on first Rx endpoint request
https://notcve.org/view.php?id=CVE-2024-56687
In the Linux kernel, the following vulnerability has been resolved: usb: musb: Fix hardware lockup on first Rx endpoint request There is a possibility that a request's callback could be invoked from usb_ep_queue() (call trace below, supplemented with missing calls): req->complete from usb_gadget_giveback_request (drivers/usb/gadget/udc/core.c:999) usb_gadget_giveback_request from musb_g_giveback (drivers/usb/musb/musb_gadget.c:147) musb_g_giveback from rxstate (drivers/usb/musb/musb_gadget.c:784) rxstate from musb_ep_restart (drivers/usb/musb/musb_gadget.c:1169) musb_ep_restart from musb_ep_restart_resume_work (drivers/usb/musb/musb_gadget.c:1176) musb_ep_restart_resume_work from musb_queue_resume_work (drivers/usb/musb/musb_core.c:2279) musb_queue_resume_work from musb_gadget_queue (drivers/usb/musb/musb_gadget.c:1241) musb_gadget_queue from usb_ep_queue (drivers/usb/gadget/udc/core.c:300) According to the docstring of usb_ep_queue(), this should not happen: "Note that @req's ->complete() callback must never be called from within usb_ep_queue() as that can create deadlock situations." In fact, a hardware lockup might occur in the following sequence: 1. The gadget is initialized using musb_gadget_enable(). 2. Meanwhile, a packet arrives, and the RXPKTRDY flag is set, raising an interrupt. 3. If IRQs are enabled, the interrupt is handled, but musb_g_rx() finds an empty queue (next_request() returns NULL). • https://git.kernel.org/stable/c/baebdf48c360080710f80699eea3affbb13d6c65 https://git.kernel.org/stable/c/c749500b28cae67410792096133ee7f282439c51 https://git.kernel.org/stable/c/5906ee3693674d734177df13a519a21bb03f730d https://git.kernel.org/stable/c/f05ad9755bb294328c3d0f429164ac6d4d08c548 https://git.kernel.org/stable/c/0c89445e6d475b78d37b64ae520831cd43af7db4 https://git.kernel.org/stable/c/3fc137386c4620305bbc2a216868c53f9245670a •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-56686 – ext4: fix race in buffer_head read fault injection
https://notcve.org/view.php?id=CVE-2024-56686
In the Linux kernel, the following vulnerability has been resolved: ext4: fix race in buffer_head read fault injection When I enabled ext4 debug for fault injection testing, I encountered the following warning: EXT4-fs error (device sda): ext4_read_inode_bitmap:201: comm fsstress: Cannot read inode bitmap - block_group = 8, inode_bitmap = 1051 WARNING: CPU: 0 PID: 511 at fs/buffer.c:1181 mark_buffer_dirty+0x1b3/0x1d0 The root cause of the issue lies in the improper implementation of ext4's buffer_head read fault injection. The actual completion of buffer_head read and the buffer_head fault injection are not atomic, which can lead to the uptodate flag being cleared on normally used buffer_heads in race conditions. [CPU0] [CPU1] [CPU2] ext4_read_inode_bitmap ext4_read_bh() <bh read complete> ext4_read_inode_bitmap if (buffer_uptodate(bh)) return bh jbd2_journal_commit_transaction __jbd2_journal_refile_buffer __jbd2_journal_unfile_buffer __jbd2_journal_temp_unlink_buffer ext4_simulate_fail_bh() clear_buffer_uptodate mark_buffer_dirty <report warning> WARN_ON_ONCE(!buffer_uptodate(bh)) The best approach would be to perform fault injection in the IO completion callback function, rather than after IO completion. However, the IO completion callback function cannot get the fault injection code in sb. Fix it by passing the result of fault injection into the bh read function, we simulate faults within the bh read function itself. This requires adding an extra parameter to the bh read functions that need fault injection. • https://git.kernel.org/stable/c/46f870d690fecc792a66730dcbbf0aa109f5f9ab https://git.kernel.org/stable/c/77035e4d27e15f87ea55929c8bb8fb1970129e2f https://git.kernel.org/stable/c/25a5acf88fed59e060405bbb48098f4a3a2c2adc https://git.kernel.org/stable/c/61832ee7fa2fbd569d129379e795038abfb0d128 https://git.kernel.org/stable/c/2f3d93e210b9c2866c8b3662adae427d5bf511ec •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-56683 – drm/vc4: hdmi: Avoid hang with debug registers when suspended
https://notcve.org/view.php?id=CVE-2024-56683
In the Linux kernel, the following vulnerability has been resolved: drm/vc4: hdmi: Avoid hang with debug registers when suspended Trying to read /sys/kernel/debug/dri/1/hdmi1_regs when the hdmi is disconnected results in a fatal system hang. This is due to the pm suspend code disabling the dvp clock. That is just a gate of the 108MHz clock in DVP_HT_RPI_MISC_CONFIG, which results in accesses hanging AXI bus. Protect against this. • https://git.kernel.org/stable/c/25eb441d55d479581a65bcc9de88bc1d86bf76c1 https://git.kernel.org/stable/c/1da00a63f0e798f0fd0dcf623b16c16e13f93615 https://git.kernel.org/stable/c/f70c25cf34f91cc6f40e79a5b7565fd0272d7396 https://git.kernel.org/stable/c/0ea29bd7d9400d3629683244d609358ed1b12075 https://git.kernel.org/stable/c/c7d474974954d9af7e0092021223d58f2de128df https://git.kernel.org/stable/c/16f351adf733a182224ad24916d7673aa6df02df https://git.kernel.org/stable/c/74f21be9990a42dc2357bcf87a13e16c6998b90e https://git.kernel.org/stable/c/223ee2567a55e4f80315c768d2969e6a3 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-56681 – crypto: bcm - add error check in the ahash_hmac_init function
https://notcve.org/view.php?id=CVE-2024-56681
In the Linux kernel, the following vulnerability has been resolved: crypto: bcm - add error check in the ahash_hmac_init function The ahash_init functions may return fails. The ahash_hmac_init should not return ok when ahash_init returns error. For an example, ahash_init will return -ENOMEM when allocation memory is error. • https://git.kernel.org/stable/c/9d12ba86f818aa9cfe9f01b750336aa441f2ffa2 https://git.kernel.org/stable/c/8f1a9a960b1107bd0e0ec3736055f5ed0e717edf https://git.kernel.org/stable/c/75e1e38e5d80d6d9011b7322698ffba3dd3db30a https://git.kernel.org/stable/c/28f8ffa945f7d7150463e15097ea73b19529d6f5 https://git.kernel.org/stable/c/4ea3e3b761e371102bb1486778e2f8dbc9e37413 https://git.kernel.org/stable/c/05f0a3f5477ecaa1cf46448504afe9e7c2e96fcc https://git.kernel.org/stable/c/ae5253313e0ea5f00c06176074592b7f493c8546 https://git.kernel.org/stable/c/ee36db8e8203420e6d5c42eb9428920c2 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-56679 – octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_common.c
https://notcve.org/view.php?id=CVE-2024-56679
In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_common.c Add error pointer check after calling otx2_mbox_get_rsp(). • https://git.kernel.org/stable/c/ab58a416c93f134b72ec7e10d8d74509c3985243 https://git.kernel.org/stable/c/785c6758ea32aca73ba9331f7d902f7ce9a25757 https://git.kernel.org/stable/c/9265b6ee754226f61bd122ec57141a781d4e0dcb https://git.kernel.org/stable/c/52c63a6a27d3178fab533fcfb4baa2ed5b8608a3 https://git.kernel.org/stable/c/4b88b202cf1ae79159a94fff9500f9be31559235 https://git.kernel.org/stable/c/d4d5139d280f5837f16d116614c05c2b4eeaf28f https://git.kernel.org/stable/c/0fbc7a5027c6f7f2c785adae3dcec22b2f2b69b3 •