CVSS: -EPSS: 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
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. • https://git.kernel.org/stable/c/4a25e41831ee851c1365d8b41decc22493b18e6d https://git.kernel.org/stable/c/0d3fb3b3e9d66f7b6346e3b90bc0ff48683539ce https://git.kernel.org/stable/c/d48cbfa90dce506030151915fa3346d67f964af4 https://git.kernel.org/stable/c/29216bb390e36daeebef66abaa02d9751330252b https://git.kernel.org/stable/c/f4fbd70e15fafe36a7583954ce189aaf5536aeec https://git.kernel.org/stable/c/40f4326ed05a3b3537556ff2a844958b9e779a98 https://git.kernel.org/stable/c/3dd9df8e5f34c6fc4217a7498c1fb3c352d4afc2 https://git.kernel.org/stable/c/d10cd53e5a7fb3b7c6f83d4d9a5ea1d97 •
CVSS: -EPSS: 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
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. • https://git.kernel.org/stable/c/6610e0893b8bc6f59b14fed7f089c5997f035f88 https://git.kernel.org/stable/c/39ad0a1ae17b54509cd9e93dcd8cec16e7c12d3f https://git.kernel.org/stable/c/44b3257ff705d63d5f00ef8ed314a0eeb7ec37f2 https://git.kernel.org/stable/c/0d68e8514d9040108ff7d1b37ca71096674b6efe https://git.kernel.org/stable/c/246f621d363988e7040f4546d20203dc713fa3e1 https://git.kernel.org/stable/c/fde56535505dde3336df438e949ef4742b6d6d6e https://git.kernel.org/stable/c/dd4b1cbcc916fad5d10c2662b62def9f05e453d4 https://git.kernel.org/stable/c/a1f0b4af90cc18b10261ecde56c6a56b2 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-56700 – media: wl128x: Fix atomicity violation in fmc_send_cmd()
https://notcve.org/view.php?id=CVE-2024-56700
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 of the function, skb = fmdev->resp_skb; when the invalid fmdev->resp_skb passes the check, a null pointer dereference error may occur at line 478, evt_hdr = (void *)skb->data; To address this issue, it is recommended to include the validity check of fmdev->resp_skb within the locked section of the function. This modification ensures that the value of fmdev->resp_skb does not change during the validation process, thereby maintaining its validity. This possible bug is found by an experimental static analysis tool developed by our team. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. • https://git.kernel.org/stable/c/e8454ff7b9a4d56f02c095bff12d3c92ef4c7fa6 https://git.kernel.org/stable/c/d16109c9fdc1b8cea4fe63b42e06e926c3f68990 https://git.kernel.org/stable/c/3c818ad07e964bca3d27adac1e1f50e1e3c9180e https://git.kernel.org/stable/c/d7408a052aa1b4f6fb6f1c7a8877b84017a07ac9 https://git.kernel.org/stable/c/ed228b74d8a500380150965d5becabf9a1e33141 https://git.kernel.org/stable/c/372dc9509122e5d45d4c12978e31c3c7d00aaca4 https://git.kernel.org/stable/c/378ce4e08ca2b1ac7bbf1d57b68643ca4226c5f8 https://git.kernel.org/stable/c/2e63c908de357048180516b84740ed62d •
CVSS: -EPSS: 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
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_handle_failed_inode+0x271/0x2e0 fs/f2fs/inode.c:986 f2fs_create+0x357/0x530 fs/f2fs/namei.c:394 lookup_open fs/namei.c:3595 [inline] open_last_lookups fs/namei.c:3694 [inline] path_openat+0x1c03/0x3590 fs/namei.c:3930 do_filp_open+0x235/0x490 fs/namei.c:3960 do_sys_openat2+0x13e/0x1d0 fs/open.c:1415 do_sys_open fs/open.c:1430 [inline] __do_sys_openat fs/open.c:1446 [inline] __se_sys_openat fs/open.c:1441 [inline] __x64_sys_openat+0x247/0x2a0 fs/open.c:1441 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_invalidate_blocks+0x35f/0x370 fs/f2fs/segment.c:2534 The root cause is: on a fuzzed image, blkaddr in nat entry may be corrupted, then it will cause system panic when using it in f2fs_invalidate_blocks(), to avoid this, let's add sanity check on nat blkaddr in truncate_node(). • https://git.kernel.org/stable/c/27d6e7eff07f8cce8e83b162d8f21a07458c860d https://git.kernel.org/stable/c/c1077078ce4589b5e5387f6b0aaa0d4534b9eb57 https://git.kernel.org/stable/c/0a5c8b3fbf6200f1c66062d307c9a52084917788 https://git.kernel.org/stable/c/6babe00ccd34fc65b78ef8b99754e32b4385f23d •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-56671 – gpio: graniterapids: Fix vGPIO driver crash
https://notcve.org/view.php?id=CVE-2024-56671
In the Linux kernel, the following vulnerability has been resolved: gpio: graniterapids: Fix vGPIO driver crash Move setting irq_chip.name from probe() function to the initialization of "irq_chip" struct in order to fix vGPIO driver crash during bootup. Crash was caused by unauthorized modification of irq_chip.name field where irq_chip struct was initialized as const. This behavior is a consequence of suboptimal implementation of gpio_irq_chip_set_chip(), which should be changed to avoid casting away const qualifier. Crash log: BUG: unable to handle page fault for address: ffffffffc0ba81c0 /#PF: supervisor write access in kernel mode /#PF: error_code(0x0003) - permissions violation CPU: 33 UID: 0 PID: 1075 Comm: systemd-udevd Not tainted 6.12.0-rc6-00077-g2e1b3cc9d7f7 #1 Hardware name: Intel Corporation Kaseyville RP/Kaseyville RP, BIOS KVLDCRB1.PGS.0026.D73.2410081258 10/08/2024 RIP: 0010:gnr_gpio_probe+0x171/0x220 [gpio_graniterapids] • https://git.kernel.org/stable/c/e631cab10c6b287a33c35953e6dbda1f7f89bc1f https://git.kernel.org/stable/c/eb9640fd1ce666610b77f5997596e9570a36378f •