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 •
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: 5EXPL: 0CVE-2024-49950 – Bluetooth: L2CAP: Fix uaf in l2cap_connect
https://notcve.org/view.php?id=CVE-2024-49950
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix uaf in l2cap_connect [Syzbot reported] BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54 CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Workqueue: hci2 hci_rx_work Call Trace: <TASK> __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline] l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline] l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825 l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514 hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline] hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ... Freed by task 5245: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:579 poison_slab_object+0xf7/0x160 mm/kasan/common.c:240 __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2256 [inline] slab_free mm/slub.c:4477 [inline] kfree+0x12a/0x3b0 mm/slub.c:4598 l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline] kref_put include/linux/kref.h:65 [inline] l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline] l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802 l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241 hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline] hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265 hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583 abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917 hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 • https://git.kernel.org/stable/c/7b064edae38d62d8587a8c574f93b53ce75ae749 https://git.kernel.org/stable/c/b22346eec479a30bfa4a02ad2c551b54809694d0 https://git.kernel.org/stable/c/b90907696c30172b809aa3dd2f0caffae761e4c6 https://git.kernel.org/stable/c/78d30ce16fdf9c301bcd8b83ce613cea079cea83 https://git.kernel.org/stable/c/a1c6174e23df10b8e5770e82d63bc6e2118a3dc7 https://git.kernel.org/stable/c/333b4fd11e89b29c84c269123f871883a30be586 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-49948 – net: add more sanity checks to qdisc_pkt_len_init()
https://notcve.org/view.php?id=CVE-2024-49948
In the Linux kernel, the following vulnerability has been resolved: net: add more sanity checks to qdisc_pkt_len_init() One path takes care of SKB_GSO_DODGY, assuming skb->len is bigger than hdr_len. virtio_net_hdr_to_skb() does not fully dissect TCP headers, it only make sure it is at least 20 bytes. It is possible for an user to provide a malicious 'GSO' packet, total length of 80 bytes. - 20 bytes of IPv4 header - 60 bytes TCP header - a small gso_size like 8 virtio_net_hdr_to_skb() would declare this packet as a normal GSO packet, because it would see 40 bytes of payload, bigger than gso_size. We need to make detect this case to not underflow qdisc_skb_cb(skb)->pkt_len. • https://git.kernel.org/stable/c/1def9238d4aa2146924994aa4b7dc861f03b9362 https://git.kernel.org/stable/c/d7d1a28f5dd57b4d83def876f8d7b4403bd37df9 https://git.kernel.org/stable/c/473426a1d53a68dd1e718e6cd00d57936993fa6c https://git.kernel.org/stable/c/566a931a1436d0e0ad13708ea55479b95426213c https://git.kernel.org/stable/c/2415f465730e48b6e38da1c7c097317bf5dd2d20 https://git.kernel.org/stable/c/27a8fabc54d2f960d47bdfbebf2bdc6e8a92a4c4 https://git.kernel.org/stable/c/9b0ee571d20a238a22722126abdfde61f1b2bdd0 https://git.kernel.org/stable/c/ff1c3cadcf405ab37dd91418a62a7acec •