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: 4EXPL: 0CVE-2024-53216 – nfsd: release svc_expkey/svc_export with rcu_work
https://notcve.org/view.php?id=CVE-2024-53216
In the Linux kernel, the following vulnerability has been resolved: nfsd: release svc_expkey/svc_export with rcu_work The last reference for `cache_head` can be reduced to zero in `c_show` and `e_show`(using `rcu_read_lock` and `rcu_read_unlock`). Consequently, `svc_export_put` and `expkey_put` will be invoked, leading to two issues: 1. The `svc_export_put` will directly free ex_uuid. However, `e_show`/`c_show` will access `ex_uuid` after `cache_put`, which can trigger a use-after-free issue, shown below. ================================================================== BUG: KASAN: slab-use-after-free in svc_export_show+0x362/0x430 [nfsd] Read of size 1 at addr ff11000010fdc120 by task cat/870 CPU: 1 UID: 0 PID: 870 Comm: cat Not tainted 6.12.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x53/0x70 print_address_description.constprop.0+0x2c/0x3a0 print_report+0xb9/0x280 kasan_report+0xae/0xe0 svc_export_show+0x362/0x430 [nfsd] c_show+0x161/0x390 [sunrpc] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 proc_reg_read+0xe1/0x140 vfs_read+0x125/0x530 ksys_read+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 830: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __kmalloc_node_track_caller_noprof+0x1bc/0x400 kmemdup_noprof+0x22/0x50 svc_export_parse+0x8a9/0xb80 [nfsd] cache_do_downcall+0x71/0xa0 [sunrpc] cache_write_procfs+0x8e/0xd0 [sunrpc] proc_reg_write+0xe1/0x140 vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 868: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kfree+0xf3/0x3e0 svc_export_put+0x87/0xb0 [nfsd] cache_purge+0x17f/0x1f0 [sunrpc] nfsd_destroy_serv+0x226/0x2d0 [nfsd] nfsd_svc+0x125/0x1e0 [nfsd] write_threads+0x16a/0x2a0 [nfsd] nfsctl_transaction_write+0x74/0xa0 [nfsd] vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e 2. We cannot sleep while using `rcu_read_lock`/`rcu_read_unlock`. However, `svc_export_put`/`expkey_put` will call path_put, which subsequently triggers a sleeping operation due to the following `dput`. ============================= WARNING: suspicious RCU usage 5.10.0-dirty #141 Not tainted ----------------------------- ... Call Trace: dump_stack+0x9a/0xd0 ___might_sleep+0x231/0x240 dput+0x39/0x600 path_put+0x1b/0x30 svc_export_put+0x17/0x80 e_show+0x1c9/0x200 seq_read_iter+0x63f/0x7c0 seq_read+0x226/0x2d0 vfs_read+0x113/0x2c0 ksys_read+0xc9/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Fix these issues by using `rcu_work` to help release `svc_expkey`/`svc_export`. • https://git.kernel.org/stable/c/9ceddd9da13434a5906255c0fc528c385aded283 https://git.kernel.org/stable/c/bd8524148dd8c123334b066faa90590ba2ef8e6f https://git.kernel.org/stable/c/2e4854599200f4d021df8ae17e69221d7c149f3e https://git.kernel.org/stable/c/ad4363a24a5746b257c0beb5d8cc68f9b62c173f https://git.kernel.org/stable/c/f8c989a0c89a75d30f899a7cabdc14d72522bb8d •
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 •