CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35959 – net/mlx5e: Fix mlx5e_priv_init() cleanup flow
https://notcve.org/view.php?id=CVE-2024-35959
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix mlx5e_priv_init() cleanup flow When mlx5e_priv_init() fails, the cleanup flow calls mlx5e_selq_cleanup which calls mlx5e_selq_apply() that assures that the `priv->state_lock` is held using lockdep_is_held(). Acquire the state_lock in mlx5e_selq_cleanup(). Kernel log: ============================= WARNING: suspicious RCU usage 6.8.0-rc3_net_next_841a9b5 #1 Not tainted ----------------------------- drivers/net/ethernet/mellanox/mlx5/core/en/selq.c:124 suspicious rcu_dereference_protected() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by systemd-modules/293: #0: ffffffffa05067b0 (devices_rwsem){++++}-{3:3}, at: ib_register_client+0x109/0x1b0 [ib_core] #1: ffff8881096c65c0 (&device->client_data_rwsem){++++}-{3:3}, at: add_client_context+0x104/0x1c0 [ib_core] stack backtrace: CPU: 4 PID: 293 Comm: systemd-modules Not tainted 6.8.0-rc3_net_next_841a9b5 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x8a/0xa0 lockdep_rcu_suspicious+0x154/0x1a0 mlx5e_selq_apply+0x94/0xa0 [mlx5_core] mlx5e_selq_cleanup+0x3a/0x60 [mlx5_core] mlx5e_priv_init+0x2be/0x2f0 [mlx5_core] mlx5_rdma_setup_rn+0x7c/0x1a0 [mlx5_core] rdma_init_netdev+0x4e/0x80 [ib_core] ? mlx5_rdma_netdev_free+0x70/0x70 [mlx5_core] ipoib_intf_init+0x64/0x550 [ib_ipoib] ipoib_intf_alloc+0x4e/0xc0 [ib_ipoib] ipoib_add_one+0xb0/0x360 [ib_ipoib] add_client_context+0x112/0x1c0 [ib_core] ib_register_client+0x166/0x1b0 [ib_core] ? 0xffffffffa0573000 ipoib_init_module+0xeb/0x1a0 [ib_ipoib] do_one_initcall+0x61/0x250 do_init_module+0x8a/0x270 init_module_from_file+0x8b/0xd0 idempotent_init_module+0x17d/0x230 __x64_sys_finit_module+0x61/0xb0 do_syscall_64+0x71/0x140 entry_SYSCALL_64_after_hwframe+0x46/0x4e </TASK> En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/mlx5e: corrige el flujo de limpieza de mlx5e_priv_init(). Cuando falla mlx5e_priv_init(), el flujo de limpieza llama a mlx5e_selq_cleanup, que llama a mlx5e_selq_apply() y garantiza que se mantenga `priv->state_lock`. usando lockdep_is_held(). • https://git.kernel.org/stable/c/8bf30be75069d6080659de9a28565c048f6cef9b https://git.kernel.org/stable/c/ad26f26abd353113dea4e8d5ebadccdab9b61e76 https://git.kernel.org/stable/c/f9ac93b6f3de34aa0bb983b9be4f69ca50fc70f3 https://git.kernel.org/stable/c/6bd77865fda662913dcb5722a66a773840370aa7 https://git.kernel.org/stable/c/ecb829459a841198e142f72fadab56424ae96519 https://access.redhat.com/security/cve/CVE-2024-35959 https://bugzilla.redhat.com/show_bug.cgi?id=2281923 •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-35958 – net: ena: Fix incorrect descriptor free behavior
https://notcve.org/view.php?id=CVE-2024-35958
In the Linux kernel, the following vulnerability has been resolved: net: ena: Fix incorrect descriptor free behavior ENA has two types of TX queues: - queues which only process TX packets arriving from the network stack - queues which only process TX packets forwarded to it by XDP_REDIRECT or XDP_TX instructions The ena_free_tx_bufs() cycles through all descriptors in a TX queue and unmaps + frees every descriptor that hasn't been acknowledged yet by the device (uncompleted TX transactions). The function assumes that the processed TX queue is necessarily from the first category listed above and ends up using napi_consume_skb() for descriptors belonging to an XDP specific queue. This patch solves a bug in which, in case of a VF reset, the descriptors aren't freed correctly, leading to crashes. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ena: soluciona el comportamiento incorrecto sin descriptor. ENA tiene dos tipos de colas TX: - colas que solo procesan paquetes TX que llegan desde la pila de red - colas que solo procesan paquetes TX reenviados a mediante instrucciones XDP_REDIRECT o XDP_TX. Ena_free_tx_bufs() recorre todos los descriptores en una cola de TX y desasigna + libera todos los descriptores que aún no han sido reconocidos por el dispositivo (transacciones de TX incompletas). La función supone que la cola TX procesada es necesariamente de la primera categoría enumerada anteriormente y termina usando napi_consume_skb() para los descriptores que pertenecen a una cola XDP específica. • https://git.kernel.org/stable/c/548c4940b9f1f527f81509468dd60b61418880b6 https://git.kernel.org/stable/c/b26aa765f7437e1bbe8db4c1641b12bd5dd378f0 https://git.kernel.org/stable/c/fdfbf54d128ab6ab255db138488f9650485795a2 https://git.kernel.org/stable/c/19ff8fed3338898b70b2aad831386c78564912e1 https://git.kernel.org/stable/c/5c7f2240d9835a7823d87f7460d8eae9f4e504c7 https://git.kernel.org/stable/c/c31baa07f01307b7ae05f3ce32b89d8e2ba0cc1d https://git.kernel.org/stable/c/bf02d9fe00632d22fa91d34749c7aacf397b6cde https://lists.debian.org/debian-lts-announce/2024/06/ •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35956 – btrfs: qgroup: fix qgroup prealloc rsv leak in subvolume operations
https://notcve.org/view.php?id=CVE-2024-35956
In the Linux kernel, the following vulnerability has been resolved: btrfs: qgroup: fix qgroup prealloc rsv leak in subvolume operations Create subvolume, create snapshot and delete subvolume all use btrfs_subvolume_reserve_metadata() to reserve metadata for the changes done to the parent subvolume's fs tree, which cannot be mediated in the normal way via start_transaction. When quota groups (squota or qgroups) are enabled, this reserves qgroup metadata of type PREALLOC. Once the operation is associated to a transaction, we convert PREALLOC to PERTRANS, which gets cleared in bulk at the end of the transaction. However, the error paths of these three operations were not implementing this lifecycle correctly. They unconditionally converted the PREALLOC to PERTRANS in a generic cleanup step regardless of errors or whether the operation was fully associated to a transaction or not. This resulted in error paths occasionally converting this rsv to PERTRANS without calling record_root_in_trans successfully, which meant that unless that root got recorded in the transaction by some other thread, the end of the transaction would not free that root's PERTRANS, leaking it. • https://git.kernel.org/stable/c/e85fde5162bf1b242cbd6daf7dba0f9b457d592b https://git.kernel.org/stable/c/2978cb474745b2d93c263008d265e89985706094 https://git.kernel.org/stable/c/14431815a4ae4bcd7c7a68b6a64c66c7712d27c9 https://git.kernel.org/stable/c/6c95336f5d8eb9ab79cd7306d71b6d0477363f8c https://git.kernel.org/stable/c/74e97958121aa1f5854da6effba70143f051b0cd •
CVSS: 8.8EPSS: 0%CPEs: 11EXPL: 0CVE-2024-35955 – kprobes: Fix possible use-after-free issue on kprobe registration
https://notcve.org/view.php?id=CVE-2024-35955
In the Linux kernel, the following vulnerability has been resolved: kprobes: Fix possible use-after-free issue on kprobe registration When unloading a module, its state is changing MODULE_STATE_LIVE -> MODULE_STATE_GOING -> MODULE_STATE_UNFORMED. Each change will take a time. `is_module_text_address()` and `__module_text_address()` works with MODULE_STATE_LIVE and MODULE_STATE_GOING. If we use `is_module_text_address()` and `__module_text_address()` separately, there is a chance that the first one is succeeded but the next one is failed because module->state becomes MODULE_STATE_UNFORMED between those operations. In `check_kprobe_address_safe()`, if the second `__module_text_address()` is failed, that is ignored because it expected a kernel_text address. But it may have failed simply because module->state has been changed to MODULE_STATE_UNFORMED. In this case, arm_kprobe() will try to modify non-exist module text address (use-after-free). To fix this problem, we should not use separated `is_module_text_address()` and `__module_text_address()`, but use only `__module_text_address()` once and do `try_module_get(module)` which is only available with MODULE_STATE_LIVE. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: kprobes: soluciona un posible problema de use after free en el registro de kprobe Al descargar un módulo, su estado cambia MODULE_STATE_LIVE -> MODULE_STATE_GOING -> MODULE_STATE_UNFORMED. • https://git.kernel.org/stable/c/1c836bad43f3e2ff71cc397a6e6ccb4e7bd116f8 https://git.kernel.org/stable/c/6a119c1a584aa7a2c6216458f1f272bf1bc93a93 https://git.kernel.org/stable/c/2a49b025c36ae749cee7ccc4b7e456e02539cdc3 https://git.kernel.org/stable/c/a1edb85e60fdab1e14db63ae8af8db3f0d798fb6 https://git.kernel.org/stable/c/28f6c37a2910f565b4f5960df52b2eccae28c891 https://git.kernel.org/stable/c/4262b6eb057d86c7829168c541654fe0d48fdac8 https://git.kernel.org/stable/c/97e813e6a143edf4208e15c72199c495ed80cea5 https://git.kernel.org/stable/c/16a544f1e013ba0660612f3fe35393b14 • CWE-416: Use After Free •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35952 – drm/ast: Fix soft lockup
https://notcve.org/view.php?id=CVE-2024-35952
In the Linux kernel, the following vulnerability has been resolved: drm/ast: Fix soft lockup There is a while-loop in ast_dp_set_on_off() that could lead to infinite-loop. This is because the register, VGACRI-Dx, checked in this API is a scratch register actually controlled by a MCU, named DPMCU, in BMC. These scratch registers are protected by scu-lock. If suc-lock is not off, DPMCU can not update these registers and then host will have soft lockup due to never updated status. DPMCU is used to control DP and relative registers to handshake with host's VGA driver. Even the most time-consuming task, DP's link training, is less than 100ms. 200ms should be enough. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/ast: corrige el bloqueo suave. • https://git.kernel.org/stable/c/594e9c04b5864b4b8b151ef4ba9521c59e0f5c54 https://git.kernel.org/stable/c/8a6fea3fcb577a543ef67683ca7105bde49a38fb https://git.kernel.org/stable/c/a81b2acd43e24e419f65df97348c76a5a1496066 https://git.kernel.org/stable/c/35768baf0fdfc47ede42d899506bad78450e9294 https://git.kernel.org/stable/c/bc004f5038220b1891ef4107134ccae44be55109 https://access.redhat.com/security/cve/CVE-2024-35952 https://bugzilla.redhat.com/show_bug.cgi?id=2281938 •