CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-53239 – ALSA: 6fire: Release resources at card release
https://notcve.org/view.php?id=CVE-2024-53239
In the Linux kernel, the following vulnerability has been resolved: ALSA: 6fire: Release resources at card release The current 6fire code tries to release the resources right after the call of usb6fire_chip_abort(). But at this moment, the card object might be still in use (as we're calling snd_card_free_when_closed()). For avoid potential UAFs, move the release of resources to the card's private_free instead of the manual call of usb6fire_chip_destroy() at the USB disconnect callback. • https://git.kernel.org/stable/c/c6d43ba816d1cf1d125bfbfc938f2a28a87facf9 https://git.kernel.org/stable/c/74357d0b5cd3ef544752bc9f21cbeee4902fae6c https://git.kernel.org/stable/c/273eec23467dfbfbd0e4c10302579ba441fb1e13 https://git.kernel.org/stable/c/f2d06d4e129e2508e356136f99bb20a332ff1a00 https://git.kernel.org/stable/c/b889a7d68d7e76b8795b754a75c91a2d561d5e8c https://git.kernel.org/stable/c/ea8cc56db659cf0ae57073e32a4735ead7bd7ee3 https://git.kernel.org/stable/c/b754e831a94f82f2593af806741392903f359168 https://git.kernel.org/stable/c/0df7f4b5cc10f5adf98be0845372e9eef •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-53227 – scsi: bfa: Fix use-after-free in bfad_im_module_exit()
https://notcve.org/view.php?id=CVE-2024-53227
In the Linux kernel, the following vulnerability has been resolved: scsi: bfa: Fix use-after-free in bfad_im_module_exit() BUG: KASAN: slab-use-after-free in __lock_acquire+0x2aca/0x3a20 Read of size 8 at addr ffff8881082d80c8 by task modprobe/25303 Call Trace: <TASK> dump_stack_lvl+0x95/0xe0 print_report+0xcb/0x620 kasan_report+0xbd/0xf0 __lock_acquire+0x2aca/0x3a20 lock_acquire+0x19b/0x520 _raw_spin_lock+0x2b/0x40 attribute_container_unregister+0x30/0x160 fc_release_transport+0x19/0x90 [scsi_transport_fc] bfad_im_module_exit+0x23/0x60 [bfa] bfad_init+0xdb/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> Allocated by task 25303: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 fc_attach_transport+0x4f/0x4740 [scsi_transport_fc] bfad_im_module_init+0x17/0x80 [bfa] bfad_init+0x23/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 25303: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x38/0x50 kfree+0x212/0x480 bfad_im_module_init+0x7e/0x80 [bfa] bfad_init+0x23/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Above issue happens as follows: bfad_init error = bfad_im_module_init() fc_release_transport(bfad_im_scsi_transport_template); if (error) goto ext; ext: bfad_im_module_exit(); fc_release_transport(bfad_im_scsi_transport_template); --> Trigger double release Don't call bfad_im_module_exit() if bfad_im_module_init() failed. • https://git.kernel.org/stable/c/7725ccfda59715ecf8f99e3b520a0b84cc2ea79e https://git.kernel.org/stable/c/0ceac8012d3ddea3317f0d82934293d05feb8af1 https://git.kernel.org/stable/c/3932c753f805a02e9364a4c58b590f21901f8490 https://git.kernel.org/stable/c/ef2c2580189ea88a0dcaf56eb3a565763a900edb https://git.kernel.org/stable/c/e76181a5be90abcc3ed8a300bd13878aa214d022 https://git.kernel.org/stable/c/8f5a97443b547b4c83f876f1d6a11df0f1fd4efb https://git.kernel.org/stable/c/c28409f851abd93b37969cac7498828ad533afd9 https://git.kernel.org/stable/c/1ffdde30a90bf8efe8f270407f4867069 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-53224 – RDMA/mlx5: Move events notifier registration to be after device registration
https://notcve.org/view.php?id=CVE-2024-53224
In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Move events notifier registration to be after device registration Move pkey change work initialization and cleanup from device resources stage to notifier stage, since this is the stage which handles this work events. Fix a race between the device deregistration and pkey change work by moving MLX5_IB_STAGE_DEVICE_NOTIFIER to be after MLX5_IB_STAGE_IB_REG in order to ensure that the notifier is deregistered before the device during cleanup. Which ensures there are no works that are being executed after the device has already unregistered which can cause the panic below. BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 630071 Comm: kworker/1:2 Kdump: loaded Tainted: G W OE --------- --- 5.14.0-162.6.1.el9_1.x86_64 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090008 02/27/2023 Workqueue: events pkey_change_handler [mlx5_ib] RIP: 0010:setup_qp+0x38/0x1f0 [mlx5_ib] Code: ee 41 54 45 31 e4 55 89 f5 53 48 89 fb 48 83 ec 20 8b 77 08 65 48 8b 04 25 28 00 00 00 48 89 44 24 18 48 8b 07 48 8d 4c 24 16 <4c> 8b 38 49 8b 87 80 0b 00 00 4c 89 ff 48 8b 80 08 05 00 00 8b 40 RSP: 0018:ffffbcc54068be20 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff954054494128 RCX: ffffbcc54068be36 RDX: ffff954004934000 RSI: 0000000000000001 RDI: ffff954054494128 RBP: 0000000000000023 R08: ffff954001be2c20 R09: 0000000000000001 R10: ffff954001be2c20 R11: ffff9540260133c0 R12: 0000000000000000 R13: 0000000000000023 R14: 0000000000000000 R15: ffff9540ffcb0905 FS: 0000000000000000(0000) GS:ffff9540ffc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010625c001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: mlx5_ib_gsi_pkey_change+0x20/0x40 [mlx5_ib] process_one_work+0x1e8/0x3c0 worker_thread+0x50/0x3b0 ? rescuer_thread+0x380/0x380 kthread+0x149/0x170 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x22/0x30 Modules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) mlx5_fwctl(OE) fwctl(OE) ib_uverbs(OE) mlx5_core(OE) mlxdevm(OE) ib_core(OE) mlx_compat(OE) psample mlxfw(OE) tls knem(OE) netconsole nfsv3 nfs_acl nfs lockd grace fscache netfs qrtr rfkill sunrpc intel_rapl_msr intel_rapl_common rapl hv_balloon hv_utils i2c_piix4 pcspkr joydev fuse ext4 mbcache jbd2 sr_mod sd_mod cdrom t10_pi sg ata_generic pci_hyperv pci_hyperv_intf hyperv_drm drm_shmem_helper drm_kms_helper hv_storvsc syscopyarea hv_netvsc sysfillrect sysimgblt hid_hyperv fb_sys_fops scsi_transport_fc hyperv_keyboard drm ata_piix crct10dif_pclmul crc32_pclmul crc32c_intel libata ghash_clmulni_intel hv_vmbus serio_raw [last unloaded: ib_core] CR2: 0000000000000000 ---[ end trace f6f8be4eae12f7bc ]--- • https://git.kernel.org/stable/c/7722f47e71e58592a2ba4437d27c802ba1c64e08 https://git.kernel.org/stable/c/921fcf2971a1e8d3b904ba2c2905b96f4ec3d4ad https://git.kernel.org/stable/c/542bd62b7a7f37182c9ef192c2bd25d118c144e4 https://git.kernel.org/stable/c/6b0acf6a94c31efa43fce4edc22413a3390f9c05 https://git.kernel.org/stable/c/ede132a5cf559f3ab35a4c28bac4f4a6c20334d8 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-53217 – NFSD: Prevent NULL dereference in nfsd4_process_cb_update()
https://notcve.org/view.php?id=CVE-2024-53217
In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent NULL dereference in nfsd4_process_cb_update() @ses is initialized to NULL. If __nfsd4_find_backchannel() finds no available backchannel session, setup_callback_client() will try to dereference @ses and segfault. • https://git.kernel.org/stable/c/dcbeaa68dbbdacbbb330a86c7fc95a28473fc209 https://git.kernel.org/stable/c/d9a0d1f6e15859ea7a86a327f28491e23deaaa62 https://git.kernel.org/stable/c/cac1405e3ff6685a438e910ad719e0cf06af90ee https://git.kernel.org/stable/c/752a75811f27300fe8131b0a1efc91960f6f88e7 https://git.kernel.org/stable/c/c5d90f9302742985a5078e42ac38de42c364c44a https://git.kernel.org/stable/c/0c3b0e326f838787d229314d4de83af9c53347e8 https://git.kernel.org/stable/c/eb51733ae5fc73d95bd857d5da26f9f65b202a79 https://git.kernel.org/stable/c/03178cd8f67227015debb700123987fe9 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-53214 – vfio/pci: Properly hide first-in-list PCIe extended capability
https://notcve.org/view.php?id=CVE-2024-53214
In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Properly hide first-in-list PCIe extended capability There are cases where a PCIe extended capability should be hidden from the user. For example, an unknown capability (i.e., capability with ID greater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionally chosen to be hidden from the user. Hiding a capability is done by virtualizing and modifying the 'Next Capability Offset' field of the previous capability so it points to the capability after the one that should be hidden. The special case where the first capability in the list should be hidden is handled differently because there is no previous capability that can be modified. In this case, the capability ID and version are zeroed while leaving the next pointer intact. This hides the capability and leaves an anchor for the rest of the capability list. However, today, hiding the first capability in the list is not done properly if the capability is unknown, as struct vfio_pci_core_device->pci_config_map is set to the capability ID during initialization but the capability ID is not properly checked later when used in vfio_config_do_rw(). This leads to the following warning [1] and to an out-of-bounds access to ecap_perms array. Fix it by checking cap_id in vfio_config_do_rw(), and if it is greater than PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for direct read only access instead of the ecap_perms array. Note that this is safe since the above is the only case where cap_id can exceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, which are already checked before). [1] WARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] CPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1 (snip) Call Trace: <TASK> ? • https://git.kernel.org/stable/c/89e1f7d4c66d85f42c3d52ea3866eb10cadf6153 https://git.kernel.org/stable/c/4464e5aa3aa4574063640f1082f7d7e323af8eb4 https://git.kernel.org/stable/c/7d121f66b67921fb3b95e0ea9856bfba53733e91 https://git.kernel.org/stable/c/0918f5643fc6c3f7801f4a22397d2cc09ba99207 https://git.kernel.org/stable/c/9567bd34aa3b986736c290c5bcba47e0182ac47a https://git.kernel.org/stable/c/6c6502d944168cbd7e03a4a08ad6488f78d73485 https://git.kernel.org/stable/c/06f2fcf49854ad05a09d09e0dbee6544fff04695 https://git.kernel.org/stable/c/949bee8065a85a5c6607c624dc05b5bc1 •