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 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-53210 – s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct()
https://notcve.org/view.php?id=CVE-2024-53210
In the Linux kernel, the following vulnerability has been resolved: s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct() Passing MSG_PEEK flag to skb_recv_datagram() increments skb refcount (skb->users) and iucv_sock_recvmsg() does not decrement skb refcount at exit. This results in skb memory leak in skb_queue_purge() and WARN_ON in iucv_sock_destruct() during socket close. To fix this decrease skb refcount by one if MSG_PEEK is set in order to prevent memory leak and WARN_ON. WARNING: CPU: 2 PID: 6292 at net/iucv/af_iucv.c:286 iucv_sock_destruct+0x144/0x1a0 [af_iucv] CPU: 2 PID: 6292 Comm: afiucv_test_msg Kdump: loaded Tainted: G W 6.10.0-rc7 #1 Hardware name: IBM 3931 A01 704 (z/VM 7.3.0) Call Trace: [<001587c682c4aa98>] iucv_sock_destruct+0x148/0x1a0 [af_iucv] [<001587c682c4a9d0>] iucv_sock_destruct+0x80/0x1a0 [af_iucv] [<001587c704117a32>] __sk_destruct+0x52/0x550 [<001587c704104a54>] __sock_release+0xa4/0x230 [<001587c704104c0c>] sock_close+0x2c/0x40 [<001587c702c5f5a8>] __fput+0x2e8/0x970 [<001587c7024148c4>] task_work_run+0x1c4/0x2c0 [<001587c7023b0716>] do_exit+0x996/0x1050 [<001587c7023b13aa>] do_group_exit+0x13a/0x360 [<001587c7023b1626>] __s390x_sys_exit_group+0x56/0x60 [<001587c7022bccca>] do_syscall+0x27a/0x380 [<001587c7049a6a0c>] __do_syscall+0x9c/0x160 [<001587c7049ce8a8>] system_call+0x70/0x98 Last Breaking-Event-Address: [<001587c682c4a9d4>] iucv_sock_destruct+0x84/0x1a0 [af_iucv] • https://git.kernel.org/stable/c/eac3731bd04c7131478722a3c148b78774553116 https://git.kernel.org/stable/c/934326aef7ac4652f81c69d18bf44eebaefc39c3 https://git.kernel.org/stable/c/42251c2d1ef1cb0822638bebb87ad9120c759673 https://git.kernel.org/stable/c/783c2c6e61c5a04eb8baea598753d5fa174dbe85 https://git.kernel.org/stable/c/9f603e66e1c59c1d25e60eb0636cb307d190782e https://git.kernel.org/stable/c/ebaf81317e42aa990ad20b113cfe3a7b20d4e937 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-53198 – xen: Fix the issue of resource not being properly released in xenbus_dev_probe()
https://notcve.org/view.php?id=CVE-2024-53198
In the Linux kernel, the following vulnerability has been resolved: xen: Fix the issue of resource not being properly released in xenbus_dev_probe() This patch fixes an issue in the function xenbus_dev_probe(). In the xenbus_dev_probe() function, within the if (err) branch at line 313, the program incorrectly returns err directly without releasing the resources allocated by err = drv->probe(dev, id). As the return value is non-zero, the upper layers assume the processing logic has failed. However, the probe operation was performed earlier without a corresponding remove operation. Since the probe actually allocates resources, failing to perform the remove operation could lead to problems. To fix this issue, we followed the resource release logic of the xenbus_dev_remove() function by adding a new block fail_remove before the fail_put block. After entering the branch if (err) at line 313, the function will use a goto statement to jump to the fail_remove block, ensuring that the previously acquired resources are correctly released, thus preventing the reference count leak. This bug was identified by an experimental static analysis tool developed by our team. • https://git.kernel.org/stable/c/4bac07c993d03434ea902d3d4290d9e45944b66c https://git.kernel.org/stable/c/87106169b4ce26f85561f953d13d1fd86d99b612 https://git.kernel.org/stable/c/0aa9e30b5b4af5dd504801689d6d84c584290a45 https://git.kernel.org/stable/c/e8823e6ff313465910edea07581627d85e68d9fd https://git.kernel.org/stable/c/3fc0996d2fefe61219375fd650601724b8cf2d30 https://git.kernel.org/stable/c/804b96f8d0a02fa10b92f28b2e042f9128ed3ffc https://git.kernel.org/stable/c/217bdce88b104269b73603b84d0ab4dd04f481bc https://git.kernel.org/stable/c/2f977a4c82d35d063f5fe198bbc501c4b •