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-49944 – sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start
https://notcve.org/view.php?id=CVE-2024-49944
In the Linux kernel, the following vulnerability has been resolved: sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start In sctp_listen_start() invoked by sctp_inet_listen(), it should set the sk_state back to CLOSED if sctp_autobind() fails due to whatever reason. Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)->reuse is already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash will be dereferenced as sk_state is LISTENING, which causes a crash as bind_hash is NULL. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617 Call Trace: <TASK> __sys_listen_socket net/socket.c:1883 [inline] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [inline] • https://git.kernel.org/stable/c/5e8f3f703ae4e4af65e2695e486b3cd198328863 https://git.kernel.org/stable/c/dd70c8a89ef99c3d53127fe19e51ef47c3f860fa https://git.kernel.org/stable/c/e7a8442195e8ebd97df467ce4742980ab57edcce https://git.kernel.org/stable/c/9230a59eda0878d7ecaa901d876aec76f57bd455 https://git.kernel.org/stable/c/7f64cb5b4d8c872296eda0fdce3bcf099eec7aa7 https://git.kernel.org/stable/c/f032e1dac30b3376c7d6026fb01a8c403c47a80d https://git.kernel.org/stable/c/e914bf68dab88815a7ae7b7a3a5e8913c8ff14a5 https://git.kernel.org/stable/c/8beee4d8dee76b67c75dc91fd8185d91e •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-49940 – l2tp: prevent possible tunnel refcount underflow
https://notcve.org/view.php?id=CVE-2024-49940
In the Linux kernel, the following vulnerability has been resolved: l2tp: prevent possible tunnel refcount underflow When a session is created, it sets a backpointer to its tunnel. When the session refcount drops to 0, l2tp_session_free drops the tunnel refcount if session->tunnel is non-NULL. However, session->tunnel is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which leaves a small window where session->tunnel is non-NULL when the tunnel refcount hasn't been bumped. Moving the assignment to l2tp_session_register is trivial but l2tp_session_create calls l2tp_session_set_header_len which uses session->tunnel to get the tunnel's encap. Add an encap arg to l2tp_session_set_header_len to avoid using session->tunnel. If l2tpv3 sessions have colliding IDs, it is possible for l2tp_v3_session_get to race with l2tp_session_register and fetch a session which doesn't yet have session->tunnel set. Add a check for this case. • https://git.kernel.org/stable/c/f7415e60c25a6108cd7955a20b2e66b6251ffe02 https://git.kernel.org/stable/c/24256415d18695b46da06c93135f5b51c548b950 •