CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-35963 – Bluetooth: hci_sock: Fix not validating setsockopt user input
https://notcve.org/view.php?id=CVE-2024-35963
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Fix not validating setsockopt user input Check user input length before copying data. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: hci_sock: solución que no valida la entrada del usuario setsockopt. Verifique la longitud de la entrada del usuario antes de copiar datos. • https://git.kernel.org/stable/c/09572fca7223bcf32c9f0d5e100d8381a81d55f4 https://git.kernel.org/stable/c/50173882bb187e70e37bac01385b9b114019bee2 https://git.kernel.org/stable/c/b2186061d6043d6345a97100460363e990af0d46 •
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: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-35961 – net/mlx5: Register devlink first under devlink lock
https://notcve.org/view.php?id=CVE-2024-35961
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Register devlink first under devlink lock In case device is having a non fatal FW error during probe, the driver will report the error to user via devlink. This will trigger a WARN_ON, since mlx5 is calling devlink_register() last. In order to avoid the WARN_ON[1], change mlx5 to invoke devl_register() first under devlink lock. [1] WARNING: CPU: 5 PID: 227 at net/devlink/health.c:483 devlink_recover_notify.constprop.0+0xb8/0xc0 CPU: 5 PID: 227 Comm: kworker/u16:3 Not tainted 6.4.0-rc5_for_upstream_min_debug_2023_06_12_12_38 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5_health0000:08:00.0 mlx5_fw_reporter_err_work [mlx5_core] RIP: 0010:devlink_recover_notify.constprop.0+0xb8/0xc0 Call Trace: <TASK> ? __warn+0x79/0x120 ? devlink_recover_notify.constprop.0+0xb8/0xc0 ? report_bug+0x17c/0x190 ? • https://git.kernel.org/stable/c/cf530217408e3686f7002429769ede59dd931151 https://git.kernel.org/stable/c/8c91c60858473731bcdaf04fda99fcbcf84420d4 https://git.kernel.org/stable/c/967caa3d37c078e5b95a32094657e6a4cad145f0 https://git.kernel.org/stable/c/c6e77aa9dd82bc18a89bf49418f8f7e961cfccc8 •
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: 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 •