CVSS: -EPSS: 0%CPEs: 14EXPL: 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/5c9807c523b4fca81d3e8e864dabc8c806402121 https://git.kernel.org/stable/c/74364cb578dcc0b6c9109519d19cbe5a5 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 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/fd89d92c1140cee8f59de336cb37fa65e359c123 https://git.kernel.org/stable/c/703b2c7e0798d263154dc8593dc2345f75dc077f 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/f60e94a83db799bde625ac8671a5b4a63 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-49956 – gfs2: fix double destroy_workqueue error
https://notcve.org/view.php?id=CVE-2024-49956
In the Linux kernel, the following vulnerability has been resolved: gfs2: fix double destroy_workqueue error When gfs2_fill_super() fails, destroy_workqueue() is called within gfs2_gl_hash_clear(), and the subsequent code path calls destroy_workqueue() on the same work queue again. This issue can be fixed by setting the work queue pointer to NULL after the first destroy_workqueue() call and checking for a NULL pointer before attempting to destroy the work queue again. • https://git.kernel.org/stable/c/30e388d573673474cbd089dec83688331c117add https://git.kernel.org/stable/c/a5336035728d77efd76306940d742a6f23debe68 https://git.kernel.org/stable/c/6cb9df81a2c462b89d2f9611009ab43ae8717841 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 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/76fb2cbf01571926da8ecf6876cc8cb07d3f5183 https://git.kernel.org/stable/c/c47843a831e0eae007ad7e848d208e675ba4c132 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/ca26e8eed9c1c6651f51f7fa38fe444f8 •
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 •