CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-56623 – scsi: qla2xxx: Fix use after free on unload
https://notcve.org/view.php?id=CVE-2024-56623
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix use after free on unload System crash is observed with stack trace warning of use after free. There are 2 signals to tell dpc_thread to terminate (UNLOADING flag and kthread_stop). On setting the UNLOADING flag when dpc_thread happens to run at the time and sees the flag, this causes dpc_thread to exit and clean up itself. When kthread_stop is called for final cleanup, this causes use after free. Remove UNLOADING signal to terminate dpc_thread. Use the kthread_stop as the main signal to exit dpc_thread. [596663.812935] kernel BUG at mm/slub.c:294! [596663.812950] invalid opcode: 0000 [#1] SMP PTI [596663.812957] CPU: 13 PID: 1475935 Comm: rmmod Kdump: loaded Tainted: G IOE --------- - - 4.18.0-240.el8.x86_64 #1 [596663.812960] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 08/20/2012 [596663.812974] RIP: 0010:__slab_free+0x17d/0x360 ... [596663.813008] Call Trace: [596663.813022] ? • https://git.kernel.org/stable/c/12f04fc8580eafb0510f805749553eb6213f323e https://git.kernel.org/stable/c/ca36d9d53745d5ec8946ef85006d4da605ea7c54 https://git.kernel.org/stable/c/b3e6f25176f248762a24d25ab8cf8c5e90874f80 https://git.kernel.org/stable/c/15369e774f27ec790f207de87c0b541e3f90b22d https://git.kernel.org/stable/c/6abf16d3c915b2feb68c1c8b25fcb71b13f98478 https://git.kernel.org/stable/c/07c903db0a2ff84b68efa1a74a4de353ea591eb0 •
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 •