CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-56622 – scsi: ufs: core: sysfs: Prevent div by zero
https://notcve.org/view.php?id=CVE-2024-56622
In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: sysfs: Prevent div by zero Prevent a division by 0 when monitoring is not enabled. • https://git.kernel.org/stable/c/1d8613a23f3c3b8f0101e453ff150e05a0d1cd4f https://git.kernel.org/stable/c/87bf3ea841a5d77beae6bb85af36b2b3848407ee https://git.kernel.org/stable/c/7b21233e5f72d10f08310689f993c1dbdfde9f2c https://git.kernel.org/stable/c/0069928727c2e95ca26c738fbe6e4b241aeaaf08 https://git.kernel.org/stable/c/9c191055c7abea4912fdb83cb9b261732b25a0c8 https://git.kernel.org/stable/c/eb48e9fc0028bed94a40a9352d065909f19e333c •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-56619 – nilfs2: fix potential out-of-bounds memory access in nilfs_find_entry()
https://notcve.org/view.php?id=CVE-2024-56619
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential out-of-bounds memory access in nilfs_find_entry() Syzbot reported that when searching for records in a directory where the inode's i_size is corrupted and has a large value, memory access outside the folio/page range may occur, or a use-after-free bug may be detected if KASAN is enabled. This is because nilfs_last_byte(), which is called by nilfs_find_entry() and others to calculate the number of valid bytes of directory data in a page from i_size and the page index, loses the upper 32 bits of the 64-bit size information due to an inappropriate type of local variable to which the i_size value is assigned. This caused a large byte offset value due to underflow in the end address calculation in the calling nilfs_find_entry(), resulting in memory access that exceeds the folio/page size. Fix this issue by changing the type of the local variable causing the bit loss from "unsigned int" to "u64". The return value of nilfs_last_byte() is also of type "unsigned int", but it is truncated so as not to exceed PAGE_SIZE and no bit loss occurs, so no change is required. • https://git.kernel.org/stable/c/2ba466d74ed74f073257f86e61519cb8f8f46184 https://git.kernel.org/stable/c/09d6d05579fd46e61abf6e457bb100ff11f3a9d3 https://git.kernel.org/stable/c/e3732102a9d638d8627d14fdf7b208462f0520e0 https://git.kernel.org/stable/c/48eb6e7404948032bbe811c5affbe39f6b316951 https://git.kernel.org/stable/c/5af8366625182f01f6d8465c9a3210574673af57 https://git.kernel.org/stable/c/c3afea07477baccdbdec4483f8d5e59d42a3f67f https://git.kernel.org/stable/c/31f7b57a77d4c82a34ddcb6ff35b5aa577ef153e https://git.kernel.org/stable/c/985ebec4ab0a28bb5910c3b1481a40fbf •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-56616 – drm/dp_mst: Fix MST sideband message body length check
https://notcve.org/view.php?id=CVE-2024-56616
In the Linux kernel, the following vulnerability has been resolved: drm/dp_mst: Fix MST sideband message body length check Fix the MST sideband message body length check, which must be at least 1 byte accounting for the message body CRC (aka message data CRC) at the end of the message. This fixes a case where an MST branch device returns a header with a correct header CRC (indicating a correctly received body length), with the body length being incorrectly set to 0. This will later lead to a memory corruption in drm_dp_sideband_append_payload() and the following errors in dmesg: UBSAN: array-index-out-of-bounds in drivers/gpu/drm/display/drm_dp_mst_topology.c:786:25 index -1 is out of range for type 'u8 [48]' Call Trace: drm_dp_sideband_append_payload+0x33d/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper] memcpy: detected field-spanning write (size 18446744073709551615) of single field "&msg->msg[msg->curlen]" at drivers/gpu/drm/display/drm_dp_mst_topology.c:791 (size 256) Call Trace: drm_dp_sideband_append_payload+0x324/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper] • https://git.kernel.org/stable/c/780fa184d4dc38ad6c4fded345ab8f9be7a63e96 https://git.kernel.org/stable/c/c58947a8d4a500902597ee1dbadf0518d7ff8801 https://git.kernel.org/stable/c/1fc1f32c4a3421b9d803f18ec3ef49db2fb5d5ef https://git.kernel.org/stable/c/bd2fccac61b40eaf08d9546acc9fef958bfe4763 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-56615 – bpf: fix OOB devmap writes when deleting elements
https://notcve.org/view.php?id=CVE-2024-56615
In the Linux kernel, the following vulnerability has been resolved: bpf: fix OOB devmap writes when deleting elements Jordy reported issue against XSKMAP which also applies to DEVMAP - the index used for accessing map entry, due to being a signed integer, causes the OOB writes. Fix is simple as changing the type from int to u32, however, when compared to XSKMAP case, one more thing needs to be addressed. When map is released from system via dev_map_free(), we iterate through all of the entries and an iterator variable is also an int, which implies OOB accesses. Again, change it to be u32. Example splat below: [ 160.724676] BUG: unable to handle page fault for address: ffffc8fc2c001000 [ 160.731662] #PF: supervisor read access in kernel mode [ 160.736876] #PF: error_code(0x0000) - not-present page [ 160.742095] PGD 0 P4D 0 [ 160.744678] Oops: Oops: 0000 [#1] PREEMPT SMP [ 160.749106] CPU: 1 UID: 0 PID: 520 Comm: kworker/u145:12 Not tainted 6.12.0-rc1+ #487 [ 160.757050] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019 [ 160.767642] Workqueue: events_unbound bpf_map_free_deferred [ 160.773308] RIP: 0010:dev_map_free+0x77/0x170 [ 160.777735] Code: 00 e8 fd 91 ed ff e8 b8 73 ed ff 41 83 7d 18 19 74 6e 41 8b 45 24 49 8b bd f8 00 00 00 31 db 85 c0 74 48 48 63 c3 48 8d 04 c7 <48> 8b 28 48 85 ed 74 30 48 8b 7d 18 48 85 ff 74 05 e8 b3 52 fa ff [ 160.796777] RSP: 0018:ffffc9000ee1fe38 EFLAGS: 00010202 [ 160.802086] RAX: ffffc8fc2c001000 RBX: 0000000080000000 RCX: 0000000000000024 [ 160.809331] RDX: 0000000000000000 RSI: 0000000000000024 RDI: ffffc9002c001000 [ 160.816576] RBP: 0000000000000000 R08: 0000000000000023 R09: 0000000000000001 [ 160.823823] R10: 0000000000000001 R11: 00000000000ee6b2 R12: dead000000000122 [ 160.831066] R13: ffff88810c928e00 R14: ffff8881002df405 R15: 0000000000000000 [ 160.838310] FS: 0000000000000000(0000) GS:ffff8897e0c40000(0000) knlGS:0000000000000000 [ 160.846528] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 160.852357] CR2: ffffc8fc2c001000 CR3: 0000000005c32006 CR4: 00000000007726f0 [ 160.859604] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 160.866847] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 160.874092] PKRU: 55555554 [ 160.876847] Call Trace: [ 160.879338] <TASK> [ 160.881477] ? __die+0x20/0x60 [ 160.884586] ? page_fault_oops+0x15a/0x450 [ 160.888746] ? • https://git.kernel.org/stable/c/546ac1ffb70d25b56c1126940e5ec639c4dd7413 https://git.kernel.org/stable/c/0f170e91d3063ca60baec4bd9f544faf3bfe29eb https://git.kernel.org/stable/c/70f3de869865f9c3da0508a5ea29f6f4c1889057 https://git.kernel.org/stable/c/ad34306ac6836e5dd096b7d0ad4aa20cb7c8d9e5 https://git.kernel.org/stable/c/98c03d05936d846073df8f550e9e8bf0dde1d77f https://git.kernel.org/stable/c/8e858930695d3ebec423e85384c95427258c294f https://git.kernel.org/stable/c/178e31df1fb3d9e0890eb471da16709cbc82edee https://git.kernel.org/stable/c/ab244dd7cf4c291f82faacdc50b45cc0f •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-56614 – xsk: fix OOB map writes when deleting elements
https://notcve.org/view.php?id=CVE-2024-56614
In the Linux kernel, the following vulnerability has been resolved: xsk: fix OOB map writes when deleting elements Jordy says: " In the xsk_map_delete_elem function an unsigned integer (map->max_entries) is compared with a user-controlled signed integer (k). Due to implicit type conversion, a large unsigned value for map->max_entries can bypass the intended bounds check: if (k >= map->max_entries) return -EINVAL; This allows k to hold a negative value (between -2147483648 and -2), which is then used as an array index in m->xsk_map[k], which results in an out-of-bounds access. spin_lock_bh(&m->lock); map_entry = &m->xsk_map[k]; // Out-of-bounds map_entry old_xs = unrcu_pointer(xchg(map_entry, NULL)); // Oob write if (old_xs) xsk_map_sock_delete(old_xs, map_entry); spin_unlock_bh(&m->lock); The xchg operation can then be used to cause an out-of-bounds write. Moreover, the invalid map_entry passed to xsk_map_sock_delete can lead to further memory corruption. " It indeed results in following splat: [76612.897343] BUG: unable to handle page fault for address: ffffc8fc2e461108 [76612.904330] #PF: supervisor write access in kernel mode [76612.909639] #PF: error_code(0x0002) - not-present page [76612.914855] PGD 0 P4D 0 [76612.917431] Oops: Oops: 0002 [#1] PREEMPT SMP [76612.921859] CPU: 11 UID: 0 PID: 10318 Comm: a.out Not tainted 6.12.0-rc1+ #470 [76612.929189] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019 [76612.939781] RIP: 0010:xsk_map_delete_elem+0x2d/0x60 [76612.944738] Code: 00 00 41 54 55 53 48 63 2e 3b 6f 24 73 38 4c 8d a7 f8 00 00 00 48 89 fb 4c 89 e7 e8 2d bf 05 00 48 8d b4 eb 00 01 00 00 31 ff <48> 87 3e 48 85 ff 74 05 e8 16 ff ff ff 4c 89 e7 e8 3e bc 05 00 31 [76612.963774] RSP: 0018:ffffc9002e407df8 EFLAGS: 00010246 [76612.969079] RAX: 0000000000000000 RBX: ffffc9002e461000 RCX: 0000000000000000 [76612.976323] RDX: 0000000000000001 RSI: ffffc8fc2e461108 RDI: 0000000000000000 [76612.983569] RBP: ffffffff80000001 R08: 0000000000000000 R09: 0000000000000007 [76612.990812] R10: ffffc9002e407e18 R11: ffff888108a38858 R12: ffffc9002e4610f8 [76612.998060] R13: ffff888108a38858 R14: 00007ffd1ae0ac78 R15: ffffc9002e4610c0 [76613.005303] FS: 00007f80b6f59740(0000) GS:ffff8897e0ec0000(0000) knlGS:0000000000000000 [76613.013517] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [76613.019349] CR2: ffffc8fc2e461108 CR3: 000000011e3ef001 CR4: 00000000007726f0 [76613.026595] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [76613.033841] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [76613.041086] PKRU: 55555554 [76613.043842] Call Trace: [76613.046331] <TASK> [76613.048468] ? __die+0x20/0x60 [76613.051581] ? page_fault_oops+0x15a/0x450 [76613.055747] ? search_extable+0x22/0x30 [76613.059649] ? • https://git.kernel.org/stable/c/fbfc504a24f53f7ebe128ab55cb5dba634f4ece8 https://git.kernel.org/stable/c/4d03f705e9d7aabebc6bfa5810f8aab6d176cbb7 https://git.kernel.org/stable/c/ed08c93d5a9801cc8f224a046411fd603c538d07 https://git.kernel.org/stable/c/f8abd03f83d5fe81e76eb93e2c4373eb9f75fd8a https://git.kernel.org/stable/c/d486b5741d987d3e0e6be4ac22cafdf94e6d1a47 https://git.kernel.org/stable/c/32cd3db7de97c0c7a018756ce66244342fd583f0 •