CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0CVE-2024-56746 – fbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem()
https://notcve.org/view.php?id=CVE-2024-56746
29 Dec 2024 — In the Linux kernel, the following vulnerability has been resolved: fbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem() When information such as info->screen_base is not ready, calling sh7760fb_free_mem() does not release memory correctly. Call dma_free_coherent() instead. In the Linux kernel, the following vulnerability has been resolved: fbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem() When information such as info->screen_base is not ready, calling sh7760fb_free_mem() d... • https://git.kernel.org/stable/c/4a25e41831ee851c1365d8b41decc22493b18e6d •
CVSS: 7.1EPSS: 0%CPEs: 9EXPL: 0CVE-2024-56739 – rtc: check if __rtc_read_time was successful in rtc_timer_do_work()
https://notcve.org/view.php?id=CVE-2024-56739
29 Dec 2024 — In the Linux kernel, the following vulnerability has been resolved: rtc: check if __rtc_read_time was successful in rtc_timer_do_work() If the __rtc_read_time call fails,, the struct rtc_time tm; may contain uninitialized data, or an illegal date/time read from the RTC hardware. When calling rtc_tm_to_ktime later, the result may be a very large value (possibly KTIME_MAX). If there are periodic timers in rtc->timerqueue, they will continually expire, may causing kernel softlockup. In the Linux kernel, the fo... • https://git.kernel.org/stable/c/6610e0893b8bc6f59b14fed7f089c5997f035f88 •
CVSS: 7.2EPSS: 0%CPEs: 8EXPL: 0CVE-2024-56724 – mfd: intel_soc_pmic_bxtwc: Use IRQ domain for TMU device
https://notcve.org/view.php?id=CVE-2024-56724
29 Dec 2024 — In the Linux kernel, the following vulnerability has been resolved: mfd: intel_soc_pmic_bxtwc: Use IRQ domain for TMU 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 not the sa... • https://git.kernel.org/stable/c/957ae5098185e763b5c06be6c3b4b6e98c048712 •
CVSS: 7.2EPSS: 0%CPEs: 8EXPL: 0CVE-2024-56723 – mfd: intel_soc_pmic_bxtwc: Use IRQ domain for PMIC devices
https://notcve.org/view.php?id=CVE-2024-56723
29 Dec 2024 — In the Linux kernel, the following vulnerability has been resolved: mfd: intel_soc_pmic_bxtwc: Use IRQ domain for PMIC devices 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 not the ... • https://git.kernel.org/stable/c/57129044f5044dcd73c22d91491906104bd331fd •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-56722 – RDMA/hns: Fix cpu stuck caused by printings during reset
https://notcve.org/view.php?id=CVE-2024-56722
29 Dec 2024 — In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix cpu stuck caused by printings during reset During reset, cmd to destroy resources such as qp, cq, and mr may fail, and error logs will be printed. When a large number of resources are destroyed, there will be lots of printings, and it may lead to a cpu stuck. Delete some unnecessary printings and replace other printing functions in these paths with the ratelimited version. In the Linux kernel, the following vulnerability has b... • https://git.kernel.org/stable/c/9a4435375cd151e07c0c38fa601b00115986091b •
CVSS: 7.8EPSS: 0%CPEs: 7EXPL: 0CVE-2024-56705 – media: atomisp: Add check for rgby_data memory allocation failure
https://notcve.org/view.php?id=CVE-2024-56705
28 Dec 2024 — In the Linux kernel, the following vulnerability has been resolved: media: atomisp: Add check for rgby_data memory allocation failure In ia_css_3a_statistics_allocate(), there is no check on the allocation result of the rgby_data memory. If rgby_data is not successfully allocated, it may trigger the assert(host_stats->rgby_data) assertion in ia_css_s3a_hmem_decode(). Adding a check to fix this potential issue. In the Linux kernel, the following vulnerability has been resolved: media: atomisp: Add check for ... • https://git.kernel.org/stable/c/a49d25364dfb9f8a64037488a39ab1f56c5fa419 •
CVSS: 7.1EPSS: 0%CPEs: 9EXPL: 0CVE-2024-56704 – 9p/xen: fix release of IRQ
https://notcve.org/view.php?id=CVE-2024-56704
28 Dec 2024 — In the Linux kernel, the following vulnerability has been resolved: 9p/xen: fix release of IRQ Kernel logs indicate an IRQ was double-freed. Pass correct device ID during IRQ release. [Dominique: remove confusing variable reset to 0] • https://git.kernel.org/stable/c/71ebd71921e451f0f942ddfe85d01e31ddc6eb88 •
CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0CVE-2024-56700 – media: wl128x: Fix atomicity violation in fmc_send_cmd()
https://notcve.org/view.php?id=CVE-2024-56700
28 Dec 2024 — In the Linux kernel, the following vulnerability has been resolved: media: wl128x: Fix atomicity violation in fmc_send_cmd() Atomicity violation occurs when the fmc_send_cmd() function is executed simultaneously with the modification of the fmdev->resp_skb value. Consider a scenario where, after passing the validity check within the function, a non-null fmdev->resp_skb variable is assigned a null value. This results in an invalid fmdev->resp_skb variable passing the validity check. As seen in the later part... • https://git.kernel.org/stable/c/e8454ff7b9a4d56f02c095bff12d3c92ef4c7fa6 •
CVSS: 7.1EPSS: 0%CPEs: 4EXPL: 0CVE-2024-56692 – f2fs: fix to do sanity check on node blkaddr in truncate_node()
https://notcve.org/view.php?id=CVE-2024-56692
28 Dec 2024 — In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on node blkaddr in truncate_node() syzbot reports a f2fs bug as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2534! RIP: 0010:f2fs_invalidate_blocks+0x35f/0x370 fs/f2fs/segment.c:2534 Call Trace: truncate_node+0x1ae/0x8c0 fs/f2fs/node.c:909 f2fs_remove_inode_page+0x5c2/0x870 fs/f2fs/node.c:1288 f2fs_evict_inode+0x879/0x15c0 fs/f2fs/inode.c:856 evict+0x4e8/0x9b0 fs/inode.c:723 f2fs_h... • https://git.kernel.org/stable/c/27d6e7eff07f8cce8e83b162d8f21a07458c860d •
CVSS: 7.2EPSS: 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 not... • https://git.kernel.org/stable/c/9c6235c8633210cc2da0882e2e9d6ff90aa37503 •