CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-35965 – Bluetooth: L2CAP: Fix not validating setsockopt user input
https://notcve.org/view.php?id=CVE-2024-35965
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix not validating setsockopt user input Check user input length before copying data. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: L2CAP: solución que no valida la entrada del usuario de setsockopt. Verifique la longitud de la entrada del usuario antes de copiar datos. • https://git.kernel.org/stable/c/33575df7be6748292f88453f29319af6d639c5c8 https://git.kernel.org/stable/c/f13b04cf65a86507ff15a9bbf37969d25be3e2a0 https://git.kernel.org/stable/c/9d42f373391211c7c8af66a3a316533a32b8a607 https://git.kernel.org/stable/c/28234f8ab69c522ba447f3e041bbfbb284c5959a https://git.kernel.org/stable/c/8ee0c132a61df9723813c40e742dc5321824daa9 https://git.kernel.org/stable/c/4f3951242ace5efc7131932e2e01e6ac6baed846 •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-35962 – netfilter: complete validation of user input
https://notcve.org/view.php?id=CVE-2024-35962
In the Linux kernel, the following vulnerability has been resolved: netfilter: complete validation of user input In my recent commit, I missed that do_replace() handlers use copy_from_sockptr() (which I fixed), followed by unsafe copy_from_sockptr_offset() calls. In all functions, we can perform the @optlen validation before even calling xt_alloc_table_info() with the following check: if ((u64)optlen < (u64)tmp.size + sizeof(tmp)) return -EINVAL; En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: validación completa de la entrada del usuario En mi confirmación reciente, omití que los controladores do_replace() usan copy_from_sockptr() (que arreglé), seguido de llamadas inseguras copy_from_sockptr_offset(). En todas las funciones, podemos realizar la validación @optlen incluso antes de llamar a xt_alloc_table_info() con la siguiente comprobación: if ((u64)optlen < (u64)tmp.size + sizeof(tmp)) return -EINVAL; • https://git.kernel.org/stable/c/0f038242b77ddfc505bf4163d4904c1abd2e74d6 https://git.kernel.org/stable/c/440e948cf0eff32cfe322dcbca3f2525354b159b https://git.kernel.org/stable/c/18aae2cb87e5faa9c5bd865260ceadac60d5a6c5 https://git.kernel.org/stable/c/81d51b9b7c95e791ba3c1a2dd77920a9d3b3f525 https://git.kernel.org/stable/c/58f2bfb789e6bd3bc24a2c9c1580f3c67aec3018 https://git.kernel.org/stable/c/cf4bc359b76144a3dd55d7c09464ef4c5f2b2b05 https://git.kernel.org/stable/c/97dab36e57c64106e1c8ebd66cbf0d2d1e52d6b7 https://git.kernel.org/stable/c/c760089aa98289b4b88a7ff5a62dd9284 •
CVSS: 9.1EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35960 – net/mlx5: Properly link new fs rules into the tree
https://notcve.org/view.php?id=CVE-2024-35960
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Properly link new fs rules into the tree Previously, add_rule_fg would only add newly created rules from the handle into the tree when they had a refcount of 1. On the other hand, create_flow_handle tries hard to find and reference already existing identical rules instead of creating new ones. These two behaviors can result in a situation where create_flow_handle 1) creates a new rule and references it, then 2) in a subsequent step during the same handle creation references it again, resulting in a rule with a refcount of 2 that is not linked into the tree, will have a NULL parent and root and will result in a crash when the flow group is deleted because del_sw_hw_rule, invoked on rule deletion, assumes node->parent is != NULL. This happened in the wild, due to another bug related to incorrect handling of duplicate pkt_reformat ids, which lead to the code in create_flow_handle incorrectly referencing a just-added rule in the same flow handle, resulting in the problem described above. Full details are at [1]. This patch changes add_rule_fg to add new rules without parents into the tree, properly initializing them and avoiding the crash. This makes it more consistent with how rules are added to an FTE in create_flow_handle. • https://git.kernel.org/stable/c/74491de937125d0c98c9b9c9208b4105717a3caa https://git.kernel.org/stable/c/de0139719cdda82806a47580ca0df06fc85e0bd2 https://git.kernel.org/stable/c/1263b0b26077b1183c3c45a0a2479573a351d423 https://git.kernel.org/stable/c/3d90ca9145f6b97b38d0c2b6b30f6ca6af9c1801 https://git.kernel.org/stable/c/7aaee12b804c5e0374e7b132b6ec2158ff33dd64 https://git.kernel.org/stable/c/2e8dc5cffc844dacfa79f056dea88002312f253f https://git.kernel.org/stable/c/5cf5337ef701830f173b4eec00a4f984adeb57a0 https://git.kernel.org/stable/c/adf67a03af39095f05d82050f15813d6f • CWE-476: NULL Pointer Dereference •
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 •