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: 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 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-49962 – ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package()
https://notcve.org/view.php?id=CVE-2024-49962
In the Linux kernel, the following vulnerability has been resolved: ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package() ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0 ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will cause NULL pointer dereference later. [ rjw: Subject and changelog edits ] • https://git.kernel.org/stable/c/4669da66ebc5b09881487f30669b0fcdb462188e https://git.kernel.org/stable/c/402b4c6b7500c7cca6972d2456a4a422801035b5 https://git.kernel.org/stable/c/cbb67e245dacd02b5e1d82733892647df1523982 https://git.kernel.org/stable/c/1c9b8775062f8d854a80caf186af57fc617d454c https://git.kernel.org/stable/c/f282db38953ad71dd4f3f8877a4e1d37e580e30a https://git.kernel.org/stable/c/4588ea78d3904bebb613b0bb025669e75800f546 https://git.kernel.org/stable/c/a907c113a8b66972f15f084d7dff960207b1f71d https://git.kernel.org/stable/c/ae5d4c7e76ba393d20366dfea1f39f245 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-49960 – ext4: fix timer use-after-free on failed mount
https://notcve.org/view.php?id=CVE-2024-49960
In the Linux kernel, the following vulnerability has been resolved: ext4: fix timer use-after-free on failed mount Syzbot has found an ODEBUG bug in ext4_fill_super The del_timer_sync function cancels the s_err_report timer, which reminds about filesystem errors daily. We should guarantee the timer is no longer active before kfree(sbi). When filesystem mounting fails, the flow goes to failed_mount3, where an error occurs when ext4_stop_mmpd is called, causing a read I/O failure. This triggers the ext4_handle_error function that ultimately re-arms the timer, leaving the s_err_report timer active before kfree(sbi) is called. Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd. • https://git.kernel.org/stable/c/9203817ba46ebba7c865c8de2aba399537b6e891 https://git.kernel.org/stable/c/fa78fb51d396f4f2f80f8e96a3b1516f394258be https://git.kernel.org/stable/c/b85569585d0154d4db1e4f9e3e6a4731d407feb0 https://git.kernel.org/stable/c/0ce160c5bdb67081a62293028dc85758a8efb22a •