CVSS: -EPSS: 0%CPEs: 12EXPL: 0CVE-2024-49958 – ocfs2: reserve space for inline xattr before attaching reflink tree
https://notcve.org/view.php?id=CVE-2024-49958
In the Linux kernel, the following vulnerability has been resolved: ocfs2: reserve space for inline xattr before attaching reflink tree One of our customers reported a crash and a corrupted ocfs2 filesystem. The crash was due to the detection of corruption. Upon troubleshooting, the fsck -fn output showed the below corruption [EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record, but fsck believes the largest valid value is 227. Clamp the next record value? n The stat output from the debugfs.ocfs2 showed the following corruption where the "Next Free Rec:" had overshot the "Count:" in the root metadata block. Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856) FS Generation: 904309833 (0x35e6ac49) CRC32: 00000000 ECC: 0000 Type: Regular Attr: 0x0 Flags: Valid Dynamic Features: (0x16) HasXattr InlineXattr Refcounted Extended Attributes Block: 0 Extended Attributes Inline Size: 256 User: 0 (root) Group: 0 (root) Size: 281320357888 Links: 1 Clusters: 141738 ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024 atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024 mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024 dtime: 0x0 -- Wed Dec 31 17:00:00 1969 Refcount Block: 2777346 Last Extblk: 2886943 Orphan Slot: 0 Sub Alloc Slot: 0 Sub Alloc Bit: 14 Tree Depth: 1 Count: 227 Next Free Rec: 230 ## Offset Clusters Block# 0 0 2310 2776351 1 2310 2139 2777375 2 4449 1221 2778399 3 5670 731 2779423 4 6401 566 2780447 ....... .... ....... ....... .... ....... The issue was in the reflink workfow while reserving space for inline xattr. The problematic function is ocfs2_reflink_xattr_inline(). • https://git.kernel.org/stable/c/ef962df057aaafd714f5c22ba3de1be459571fdf https://git.kernel.org/stable/c/3a32958d2ac96070c53d04bd8e013c97b260b5e6 https://git.kernel.org/stable/c/93f26306db89c9dc37885b76a1082e6d54d23b16 https://git.kernel.org/stable/c/26a849f49fb3347d126a0ed6611173f903374ef4 https://git.kernel.org/stable/c/1e7e4c9ae2a78a6791a2ca91a6a400f94855f01e https://git.kernel.org/stable/c/1926bf8ae44d80c9f50103f11fc4f17e2e2bf684 https://git.kernel.org/stable/c/aac31d654a0a31cb0d2fa36ae694f4e164a52707 https://git.kernel.org/stable/c/020f5c53c17f66c0a8f2d37dad27ace30 •
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 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-49955 – ACPI: battery: Fix possible crash when unregistering a battery hook
https://notcve.org/view.php?id=CVE-2024-49955
In the Linux kernel, the following vulnerability has been resolved: ACPI: battery: Fix possible crash when unregistering a battery hook When a battery hook returns an error when adding a new battery, then the battery hook is automatically unregistered. However the battery hook provider cannot know that, so it will later call battery_hook_unregister() on the already unregistered battery hook, resulting in a crash. Fix this by using the list head to mark already unregistered battery hooks as already being unregistered so that they can be ignored by battery_hook_unregister(). • https://git.kernel.org/stable/c/fa93854f7a7ed63d054405bf3779247d5300edd3 https://git.kernel.org/stable/c/da964de4c18199e14b961b5b2e5e6570552a313c https://git.kernel.org/stable/c/07b98400cb0285a6348188aa8c5ec6a2ae0551f7 https://git.kernel.org/stable/c/ca1fb7942a287b40659cc79551a1de54a2c2e7d5 https://git.kernel.org/stable/c/ce31847f109c3a5b2abdd19d7bcaafaacfde53de https://git.kernel.org/stable/c/ca26e8eed9c1c6651f51f7fa38fe444f8573cd1b https://git.kernel.org/stable/c/9f469ef1c79dac7f9ac1518643a33703918f7e13 https://git.kernel.org/stable/c/76959aff14a0012ad6b984ec7686d163d •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-49954 – static_call: Replace pointless WARN_ON() in static_call_module_notify()
https://notcve.org/view.php?id=CVE-2024-49954
In the Linux kernel, the following vulnerability has been resolved: static_call: Replace pointless WARN_ON() in static_call_module_notify() static_call_module_notify() triggers a WARN_ON(), when memory allocation fails in __static_call_add_module(). That's not really justified, because the failure case must be correctly handled by the well known call chain and the error code is passed through to the initiating userspace application. A memory allocation fail is not a fatal problem, but the WARN_ON() takes the machine out when panic_on_warn is set. Replace it with a pr_warn(). • https://git.kernel.org/stable/c/9183c3f9ed710a8edf1a61e8a96d497258d26e08 https://git.kernel.org/stable/c/bc9356513d56b688775497b7ac6f2b967f46a80c https://git.kernel.org/stable/c/ea2cdf4da093d0482f0ef36ba971e2e0c7673425 https://git.kernel.org/stable/c/e67534bd31d79952b50e791e92adf0b3e6c13b8c https://git.kernel.org/stable/c/85a104aaef1f56623acc10ba4c42d5f046ba65b7 https://git.kernel.org/stable/c/b83bef74c121a3311240fc4002d23486b85355e4 https://git.kernel.org/stable/c/fe513c2ef0a172a58f158e2e70465c4317f0a9a2 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-49952 – netfilter: nf_tables: prevent nf_skb_duplicated corruption
https://notcve.org/view.php?id=CVE-2024-49952
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: prevent nf_skb_duplicated corruption syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write per-cpu variable nf_skb_duplicated in an unsafe way [1]. Disabling preemption as hinted by the splat is not enough, we have to disable soft interrupts as well. [1] BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 include/linux/netfilter.h:269 NF_HOOK_COND include/linux/netfilter.h:302 [inline] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [inline] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [inline] __se_sys_sendmmsg net/socket.c:2763 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f4ce4f7def9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9 RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006 RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68 </TASK> • https://git.kernel.org/stable/c/d877f07112f1e5a247c6b585c971a93895c9f738 https://git.kernel.org/stable/c/531754952f5dfc4b141523088147071d6e6112c4 https://git.kernel.org/stable/c/38e3fd0c4a2616052eb3c8f4e6f32d1ff47cd663 https://git.kernel.org/stable/c/b40b027a0c0cc1cb9471a13f9730bb2fff12a15b https://git.kernel.org/stable/c/4e3542f40f3a94efa59ea328e307c50601ed7065 https://git.kernel.org/stable/c/f839c5cd348201fec440d987cbca9b979bdb4fa7 https://git.kernel.org/stable/c/752e1924604254f1708f3e3700283a86ebdd325d https://git.kernel.org/stable/c/92ceba94de6fb4cee2bf40b485979c342 •