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: 5EXPL: 0CVE-2024-49961 – media: i2c: ar0521: Use cansleep version of gpiod_set_value()
https://notcve.org/view.php?id=CVE-2024-49961
In the Linux kernel, the following vulnerability has been resolved: media: i2c: ar0521: Use cansleep version of gpiod_set_value() If we use GPIO reset from I2C port expander, we must use *_cansleep() variant of GPIO functions. This was not done in ar0521_power_on()/ar0521_power_off() functions. Let's fix that. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x74/0x7c Modules linked in: CPU: 0 PID: 11 Comm: kworker/u16:0 Not tainted 6.10.0 #53 Hardware name: Diasom DS-RK3568-SOM-EVB (DT) Workqueue: events_unbound deferred_probe_work_func pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : gpiod_set_value+0x74/0x7c lr : ar0521_power_on+0xcc/0x290 sp : ffffff8001d7ab70 x29: ffffff8001d7ab70 x28: ffffff80027dcc90 x27: ffffff8003c82000 x26: ffffff8003ca9250 x25: ffffffc080a39c60 x24: ffffff8003ca9088 x23: ffffff8002402720 x22: ffffff8003ca9080 x21: ffffff8003ca9088 x20: 0000000000000000 x19: ffffff8001eb2a00 x18: ffffff80efeeac80 x17: 756d2d6332692f30 x16: 0000000000000000 x15: 0000000000000000 x14: ffffff8001d91d40 x13: 0000000000000016 x12: ffffffc080e98930 x11: ffffff8001eb2880 x10: 0000000000000890 x9 : ffffff8001d7a9f0 x8 : ffffff8001d92570 x7 : ffffff80efeeac80 x6 : 000000003fc6e780 x5 : ffffff8001d91c80 x4 : 0000000000000002 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: gpiod_set_value+0x74/0x7c ar0521_power_on+0xcc/0x290 ... • https://git.kernel.org/stable/c/852b50aeed153b513c0b36298559114fab0fab80 https://git.kernel.org/stable/c/9f08876d766755a92f1b9543ae3ee21bfc596fb8 https://git.kernel.org/stable/c/625a77b68c96349c16fcc1faa42784313e0b1a85 https://git.kernel.org/stable/c/2423b60a2d6d27e5f66c5021b494463aef2db212 https://git.kernel.org/stable/c/3cf00ecfbf11ee8e6afff306a5bdcff4bf95d2cf https://git.kernel.org/stable/c/bee1aed819a8cda47927436685d216906ed17f62 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 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/cf3196e5e2f36cd80dab91ffae402e13935724bc 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 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-49959 – jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error
https://notcve.org/view.php?id=CVE-2024-49959
In the Linux kernel, the following vulnerability has been resolved: jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: <TASK> add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corrupt when updating journal superblock fails") to make jbd2_cleanup_journal_tail return the correct error code. • https://git.kernel.org/stable/c/8c3f25d8950c3e9fe6c9849f88679b3f2a071550 https://git.kernel.org/stable/c/801a35dfef6996f3d5eaa96a59caf00440d9165e https://git.kernel.org/stable/c/d5dc65370a746750dbb2f03eabcf86b18db65f32 https://git.kernel.org/stable/c/481e8f18a290e39e04ddb7feb2bb2a2cc3b213ed https://git.kernel.org/stable/c/ec7f8337c98ad281020ad1f11ba492462d80737a https://git.kernel.org/stable/c/70bae48377a2c4296fd3caf4caf8f11079111019 https://git.kernel.org/stable/c/1c62dc0d82c62f0dc8fcdc4843208e522acccaf5 https://git.kernel.org/stable/c/3ced0fe6c0eff032733ea8b38778b3470 •