CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-56691 – mfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C device
https://notcve.org/view.php?id=CVE-2024-56691
28 Dec 2024 — In the Linux kernel, the following vulnerability has been resolved: mfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C device While design wise the idea of converting the driver to use the hierarchy of the IRQ chips is correct, the implementation has (inherited) flaws. This was unveiled when platform_get_irq() had started WARN() on IRQ 0 that is supposed to be a Linux IRQ number (also known as vIRQ). Rework the driver to respect IRQ domain when creating each MFD device separately, as the domain is ... • https://git.kernel.org/stable/c/9c6235c8633210cc2da0882e2e9d6ff90aa37503 •
CVSS: -EPSS: 0%CPEs: 11EXPL: 0CVE-2024-56690 – crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSY
https://notcve.org/view.php?id=CVE-2024-56690
28 Dec 2024 — In the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSY Since commit 8f4f68e788c3 ("crypto: pcrypt - Fix hungtask for PADATA_RESET"), the pcrypt encryption and decryption operations return -EAGAIN when the CPU goes online or offline. In alg_test(), a WARN is generated when pcrypt_aead_decrypt() or pcrypt_aead_encrypt() returns -EAGAIN, the unnecessary panic will occur when panic_on_warn set 1. Fix this issue by... • https://git.kernel.org/stable/c/039fec48e062504f14845124a1a25eb199b2ddc0 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-56689 – PCI: endpoint: epf-mhi: Avoid NULL dereference if DT lacks 'mmio'
https://notcve.org/view.php?id=CVE-2024-56689
28 Dec 2024 — In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: epf-mhi: Avoid NULL dereference if DT lacks 'mmio' If platform_get_resource_byname() fails and returns NULL because DT lacks an 'mmio' property for the MHI endpoint, dereferencing res->start will cause a NULL pointer access. Add a check to prevent it. [kwilczynski: error message update per the review feedback] [bhelgaas: commit log] • https://git.kernel.org/stable/c/1bf5f25324f7f6a52c3eb566ec5f78f6a901db96 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-56688 – sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport
https://notcve.org/view.php?id=CVE-2024-56688
28 Dec 2024 — In the Linux kernel, the following vulnerability has been resolved: sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport Since transport->sock has been set to NULL during reset transport, XPRT_SOCK_UPD_TIMEOUT also needs to be cleared. Otherwise, the xs_tcp_set_socket_timeouts() may be triggered in xs_tcp_send_request() to dereference the transport->sock that has been set to NULL. • https://git.kernel.org/stable/c/7196dbb02ea05835b9ee56910ee82cb55422c7f1 •
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
28 Dec 2024 — 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) rxst... • https://git.kernel.org/stable/c/baebdf48c360080710f80699eea3affbb13d6c65 •
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
28 Dec 2024 — 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 ... • https://git.kernel.org/stable/c/46f870d690fecc792a66730dcbbf0aa109f5f9ab •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-56685 – ASoC: mediatek: Check num_codecs is not zero to avoid panic during probe
https://notcve.org/view.php?id=CVE-2024-56685
28 Dec 2024 — In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: Check num_codecs is not zero to avoid panic during probe Following commit 13f58267cda3 ("ASoC: soc.h: don't create dummy Component via COMP_DUMMY()"), COMP_DUMMY() became an array with zero length, and only gets populated with the dummy struct after the card is registered. Since the sound card driver's probe happens before the card registration, accessing any of the members of a dummy component during probe will result in ... • https://git.kernel.org/stable/c/13f58267cda3d6946c8f4de368ad5d4a003baa61 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-56684 – mailbox: mtk-cmdq: fix wrong use of sizeof in cmdq_get_clocks()
https://notcve.org/view.php?id=CVE-2024-56684
28 Dec 2024 — In the Linux kernel, the following vulnerability has been resolved: mailbox: mtk-cmdq: fix wrong use of sizeof in cmdq_get_clocks() It should be size of the struct clk_bulk_data, not data pointer pass to devm_kcalloc(). • https://git.kernel.org/stable/c/aa1609f571caba0db102c611829d48adf226bb70 •
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
28 Dec 2024 — 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 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-56682 – irqchip/riscv-aplic: Prevent crash when MSI domain is missing
https://notcve.org/view.php?id=CVE-2024-56682
28 Dec 2024 — In the Linux kernel, the following vulnerability has been resolved: irqchip/riscv-aplic: Prevent crash when MSI domain is missing If the APLIC driver is probed before the IMSIC driver, the parent MSI domain will be missing, which causes a NULL pointer dereference in msi_create_device_irq_domain(). Avoid this by deferring probe until the parent MSI domain is available. Use dev_err_probe() to avoid printing an error message when returning -EPROBE_DEFER. • https://git.kernel.org/stable/c/ca8df97fe6798afbe395fc4a8e23bac0c7fbd248 •