CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-49967 – ext4: no need to continue when the number of entries is 1
https://notcve.org/view.php?id=CVE-2024-49967
In the Linux kernel, the following vulnerability has been resolved: ext4: no need to continue when the number of entries is 1 • https://git.kernel.org/stable/c/ac27a0ec112a089f1a5102bc8dffc79c8c815571 https://git.kernel.org/stable/c/64c8c484242b141998f7408596ddb2dc6da4b1d3 https://git.kernel.org/stable/c/cdfd6ef391df332c9abb854f4530dd7bfbd71dc4 https://git.kernel.org/stable/c/133ff0d78f1b160de011647bb65807195ca5d1ca https://git.kernel.org/stable/c/aca593e6070e21979430c344e9cb0b272a9e7e10 https://git.kernel.org/stable/c/a02d7f5b24193aed451ac67aad3453472e79dc78 https://git.kernel.org/stable/c/2d64e7dada22ab589d1ac216a3661074d027f25e https://git.kernel.org/stable/c/fe192515d2937b8ed2d21921b558a06dd •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-49966 – ocfs2: cancel dqi_sync_work before freeing oinfo
https://notcve.org/view.php?id=CVE-2024-49966
In the Linux kernel, the following vulnerability has been resolved: ocfs2: cancel dqi_sync_work before freeing oinfo ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled: ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqi_sync_work first. BTW, return status instead of -1 when .read_file_info fails. • https://git.kernel.org/stable/c/171bf93ce11f4c9929fdce6ce63df8da2f3c4475 https://git.kernel.org/stable/c/fc5cc716dfbdc5fd5f373ff3b51358174cf88bfc https://git.kernel.org/stable/c/89043e7ed63c7fc141e68ea5a79758ed24b6c699 https://git.kernel.org/stable/c/14114d8148db07e7946fb06b56a50cfa425e26c7 https://git.kernel.org/stable/c/4173d1277c00baeedaaca76783e98b8fd0e3c08d https://git.kernel.org/stable/c/bbf41277df8b33fbedf4750a9300c147e8f104eb https://git.kernel.org/stable/c/ef768020366f47d23f39c4f57bcb03af6d1e24b3 https://git.kernel.org/stable/c/a4346c04d055bf7e184c18a73dbd23b6a •
CVSS: -EPSS: 0%CPEs: 12EXPL: 0CVE-2024-49965 – ocfs2: remove unreasonable unlock in ocfs2_read_blocks
https://notcve.org/view.php?id=CVE-2024-49965
In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove unreasonable unlock in ocfs2_read_blocks Patch series "Misc fixes for ocfs2_read_blocks", v5. This series contains 2 fixes for ocfs2_read_blocks(). The first patch fix the issue reported by syzbot, which detects bad unlock balance in ocfs2_read_blocks(). The second patch fixes an issue reported by Heming Zhao when reviewing above fix. This patch (of 2): There was a lock release before exiting, so remove the unreasonable unlock. • https://git.kernel.org/stable/c/6c150df9c2e80b5cf86f5a0d98beb7390ad63bfc https://git.kernel.org/stable/c/cf76c78595ca87548ca5e45c862ac9e0949c4687 https://git.kernel.org/stable/c/01f93d5e36753fc4d06ec67f05ce78c9c6f2dd56 https://git.kernel.org/stable/c/65cbd1279f4b999d56a838344a30642db24cd215 https://git.kernel.org/stable/c/97e1db17bc1ef4c2e1789bc9323c7be44fba53f8 https://git.kernel.org/stable/c/5245f109b4afb6595360d4c180d483a6d2009a59 https://git.kernel.org/stable/c/9753bcb17b36c9add9b32c61766ddf8d2d161911 https://git.kernel.org/stable/c/3f1ca6ba5452d53c598a45d21267a2c0c •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-49964 – mm/hugetlb: fix memfd_pin_folios free_huge_pages leak
https://notcve.org/view.php?id=CVE-2024-49964
In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix memfd_pin_folios free_huge_pages leak memfd_pin_folios followed by unpin_folios fails to restore free_huge_pages if the pages were not already faulted in, because the folio refcount for pages created by memfd_alloc_folio never goes to 0. memfd_pin_folios needs another folio_put to undo the folio_try_get below: memfd_alloc_folio() alloc_hugetlb_folio_nodemask() dequeue_hugetlb_folio_nodemask() dequeue_hugetlb_folio_node_exact() folio_ref_unfreeze(folio, 1); ; adds 1 refcount folio_try_get() ; adds 1 refcount hugetlb_add_to_page_cache() ; adds 512 refcount (on x86) With the fix, after memfd_pin_folios + unpin_folios, the refcount for the (unfaulted) page is 512, which is correct, as the refcount for a faulted unpinned page is 513. • https://git.kernel.org/stable/c/89c1905d9c140372b7f50ef48f42378cf85d9bc5 https://git.kernel.org/stable/c/59e081ff2e91bbf19b8c1ecb75b031f778858383 https://git.kernel.org/stable/c/c56b6f3d801d7ec8965993342bdd9e2972b6cb8e •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-49963 – mailbox: bcm2835: Fix timeout during suspend mode
https://notcve.org/view.php?id=CVE-2024-49963
In the Linux kernel, the following vulnerability has been resolved: mailbox: bcm2835: Fix timeout during suspend mode During noirq suspend phase the Raspberry Pi power driver suffer of firmware property timeouts. The reason is that the IRQ of the underlying BCM2835 mailbox is disabled and rpi_firmware_property_list() will always run into a timeout [1]. Since the VideoCore side isn't consider as a wakeup source, set the IRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled during suspend-resume cycle. [1] PM: late suspend of devices complete after 1.754 msecs WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x204/0x22c Firmware transaction 0x00028001 timeout Modules linked in: CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x44 dump_stack_lvl from __warn+0x88/0xec __warn from warn_slowpath_fmt+0x7c/0xb0 warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c rpi_firmware_property_list from rpi_firmware_property+0x68/0x8c rpi_firmware_property from rpi_firmware_set_power+0x54/0xc0 rpi_firmware_set_power from _genpd_power_off+0xe4/0x148 _genpd_power_off from genpd_sync_power_off+0x7c/0x11c genpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0 genpd_finish_suspend from dpm_run_callback+0x78/0xd0 dpm_run_callback from device_suspend_noirq+0xc0/0x238 device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168 dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac suspend_devices_and_enter from pm_suspend+0x254/0x2e4 pm_suspend from state_store+0xa8/0xd4 state_store from kernfs_fop_write_iter+0x154/0x1a0 kernfs_fop_write_iter from vfs_write+0x12c/0x184 vfs_write from ksys_write+0x78/0xc0 ksys_write from ret_fast_syscall+0x0/0x54 Exception stack(0xcc93dfa8 to 0xcc93dff0) [...] PM: noirq suspend of devices complete after 3095.584 msecs • https://git.kernel.org/stable/c/0bae6af6d704f026d4938739786e0a69d50177ca https://git.kernel.org/stable/c/4e1e03760ee7cc4779b6306867fe0fc02921b963 https://git.kernel.org/stable/c/b0de20de29b13950493a36bd4cf531200eb0e807 https://git.kernel.org/stable/c/32ee78823dea2d54adaf6e05f86622eba359e091 https://git.kernel.org/stable/c/df293ea78740a41384d648041f38f645700288e1 https://git.kernel.org/stable/c/90320cfc07b7d6e7a58fd8168f6380ec52ff0251 https://git.kernel.org/stable/c/10a58555e0bb5cc4673c8bb73b8afc5fa651f0ac https://git.kernel.org/stable/c/e65a9af05a0b59ebeba28e5e82265a233 •