CVSS: -EPSS: 0%CPEs: 7EXPL: 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/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/a4346c04d055bf7e184c18a73dbd23b6a9811118 https://git.kernel.org/stable/c/0d707a33c84b371cb66120e198eed3374726ddd8 https://git.kernel.org/stable/c/35fccce29feb3706f649726d410122dd8 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 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/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/ae5d4c7e76ba393d20366dfea1f39f24560ffb1d https://git.kernel.org/stable/c/a5242874488eba2b9062985bf13743c029821330 •
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 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 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/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/3ced0fe6c0eff032733ea8b38778b34707270138 https://git.kernel.org/stable/c/c6bf043b210eac67d35a114e345c4e5585672913 https://git.kernel.org/stable/c/f5cacdc6f2bb2a9bf214469dd7112b43d •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-49957 – ocfs2: fix null-ptr-deref when journal load failed.
https://notcve.org/view.php?id=CVE-2024-49957
In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix null-ptr-deref when journal load failed. During the mounting process, if journal_reset() fails because of too short journal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer. Subsequently, ocfs2_journal_shutdown() calls jbd2_journal_flush()->jbd2_cleanup_journal_tail()-> __jbd2_update_log_tail()->jbd2_journal_update_sb_log_tail() ->lock_buffer(journal->j_sb_buffer), resulting in a null-pointer dereference error. To resolve this issue, we should check the JBD2_LOADED flag to ensure the journal was properly loaded. Additionally, use journal instead of osb->journal directly to simplify the code. • https://git.kernel.org/stable/c/f6f50e28f0cb8d7bcdfaacc83129f005dede11b1 https://git.kernel.org/stable/c/bf605ae98dab5c15c5b631d4d7f88898cb41b649 https://git.kernel.org/stable/c/ff55291fb36779819211b596da703389135f5b05 https://git.kernel.org/stable/c/82dfdd1e31e774578f76ce6dc90c834f96403a0f https://git.kernel.org/stable/c/86a89e75e9e4dfa768b97db466ad6bedf2e7ea5b https://git.kernel.org/stable/c/f60e94a83db799bde625ac8671a5b4a6354e7120 https://git.kernel.org/stable/c/387bf565cc03e2e8c720b8b4798efea4aacb6962 https://git.kernel.org/stable/c/5784d9fcfd43bd853654bb80c87ef293b •