CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-27019 – netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get()
https://notcve.org/view.php?id=CVE-2024-27019
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get() nft_unregister_obj() can concurrent with __nft_obj_type_get(), and there is not any protection when iterate over nf_tables_objects list in __nft_obj_type_get(). Therefore, there is potential data-race of nf_tables_objects list entry. Use list_for_each_entry_rcu() to iterate over nf_tables_objects list in __nft_obj_type_get(), and use rcu_read_lock() in the caller nft_obj_type_get() to protect the entire type query process. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: nf_tables: corrige una posible ejecución de datos en __nft_obj_type_get() nft_unregister_obj() puede concurrir con __nft_obj_type_get(), y no hay ninguna protección cuando se itera sobre la lista de nf_tables_objects en __nft_obj_type_get() . Por lo tanto, existe una posible ejecución de datos de la entrada de la lista nf_tables_objects. Utilice list_for_each_entry_rcu() para iterar sobre la lista nf_tables_objects en __nft_obj_type_get(), y utilice rcu_read_lock() en el llamador nft_obj_type_get() para proteger todo el proceso de consulta de tipos. • https://git.kernel.org/stable/c/e50092404c1bc7aaeb0a0f4077fa6f07b073a20f https://git.kernel.org/stable/c/cade34279c2249eafe528564bd2e203e4ff15f88 https://git.kernel.org/stable/c/379bf7257bc5f2a1b1ca8514e08a871b7bf6d920 https://git.kernel.org/stable/c/df7c0fb8c2b9f9cac65659332581b19682a71349 https://git.kernel.org/stable/c/ad333578f736d56920e090d7db1f8dec891d815e https://git.kernel.org/stable/c/4ca946b19caf655a08d5e2266d4d5526025ebb73 https://git.kernel.org/stable/c/d78d867dcea69c328db30df665be5be7d0148484 https://access.redhat.com/security/cve/CVE-2024-27019 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-27017 – netfilter: nft_set_pipapo: walk over current view on netlink dump
https://notcve.org/view.php?id=CVE-2024-27017
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: walk over current view on netlink dump The generation mask can be updated while netlink dump is in progress. The pipapo set backend walk iterator cannot rely on it to infer what view of the datastructure is to be used. Add notation to specify if user wants to read/update the set. Based on patch from Florian Westphal. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nft_set_pipapo: recorra la vista actual en el volcado de netlink. La máscara de generación se puede actualizar mientras el volcado de netlink está en progreso. El iterador de recorrido backend del conjunto pipapo no puede confiar en él para inferir qué vista de la estructura de datos se va a utilizar. • https://git.kernel.org/stable/c/0d836f917520300a8725a5dbdad4406438d0cead https://git.kernel.org/stable/c/2b84e215f87443c74ac0aa7f76bb172d43a87033 https://git.kernel.org/stable/c/2a90da8e0dd50f42e577988f4219f4f4cd3616b7 https://git.kernel.org/stable/c/45eb6944d0f55102229115de040ef3a48841434a https://git.kernel.org/stable/c/f661383b5f1aaac3fe121b91e04332944bc90193 https://git.kernel.org/stable/c/52735a010f37580b3a569a996f878fdd87425650 https://git.kernel.org/stable/c/f24d8abc2bb8cbf31ec713336e402eafa8f42f60 https://git.kernel.org/stable/c/721715655c72640567e8742567520c998 •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-27016 – netfilter: flowtable: validate pppoe header
https://notcve.org/view.php?id=CVE-2024-27016
In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: validate pppoe header Ensure there is sufficient room to access the protocol field of the PPPoe header. Validate it once before the flowtable lookup, then use a helper function to access protocol field. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: flowtable: validar encabezado pppoe Asegúrese de que haya suficiente espacio para acceder al campo de protocolo del encabezado PPPoe. Valídelo una vez antes de la búsqueda de la tabla de flujo, luego use una función auxiliar para acceder al campo de protocolo. • https://git.kernel.org/stable/c/72efd585f7144a047f7da63864284764596ccad9 https://git.kernel.org/stable/c/d06977b9a4109f8738bb276125eb6a0b772bc433 https://git.kernel.org/stable/c/8bf7c76a2a207ca2b4cfda0a279192adf27678d7 https://git.kernel.org/stable/c/a2471d271042ea18e8a6babc132a8716bb2f08b9 https://git.kernel.org/stable/c/cf366ee3bc1b7d1c76a882640ba3b3f8f1039163 https://git.kernel.org/stable/c/87b3593bed1868b2d9fe096c01bcdf0ea86cbebf https://access.redhat.com/security/cve/CVE-2024-27016 https://bugzilla.redhat.com/show_bug.cgi?id=2278264 •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-27015 – netfilter: flowtable: incorrect pppoe tuple
https://notcve.org/view.php?id=CVE-2024-27015
In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: incorrect pppoe tuple pppoe traffic reaching ingress path does not match the flowtable entry because the pppoe header is expected to be at the network header offset. This bug causes a mismatch in the flow table lookup, so pppoe packets enter the classical forwarding path. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: tabla de flujo: tupla de pppoe incorrecta. El tráfico de pppoe que llega a la ruta de entrada no coincide con la entrada de la tabla de flujo porque se espera que el encabezado de pppoe esté en el desplazamiento del encabezado de red. Este error provoca una discrepancia en la búsqueda de la tabla de flujo, por lo que los paquetes pppoe ingresan a la ruta de reenvío clásica. • https://git.kernel.org/stable/c/72efd585f7144a047f7da63864284764596ccad9 https://git.kernel.org/stable/c/e719b52d0c56989b0f3475a03a6d64f182c85b56 https://git.kernel.org/stable/c/f1c3c61701a0b12f4906152c1626a5de580ea3d2 https://git.kernel.org/stable/c/4ed82dd368ad883dc4284292937b882f044e625d https://git.kernel.org/stable/c/e3f078103421642fcd5f05c5e70777feb10f000d https://git.kernel.org/stable/c/6db5dc7b351b9569940cd1cf445e237c42cd6d27 •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-27014 – net/mlx5e: Prevent deadlock while disabling aRFS
https://notcve.org/view.php?id=CVE-2024-27014
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Prevent deadlock while disabling aRFS When disabling aRFS under the `priv->state_lock`, any scheduled aRFS works are canceled using the `cancel_work_sync` function, which waits for the work to end if it has already started. However, while waiting for the work handler, the handler will try to acquire the `state_lock` which is already acquired. The worker acquires the lock to delete the rules if the state is down, which is not the worker's responsibility since disabling aRFS deletes the rules. Add an aRFS state variable, which indicates whether the aRFS is enabled and prevent adding rules when the aRFS is disabled. Kernel log: ====================================================== WARNING: possible circular locking dependency detected 6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G I ------------------------------------------------------ ethtool/386089 is trying to acquire lock: ffff88810f21ce68 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0 but task is already holding lock: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&priv->state_lock){+.+.}-{3:3}: __mutex_lock+0x80/0xc90 arfs_handle_work+0x4b/0x3b0 [mlx5_core] process_one_work+0x1dc/0x4a0 worker_thread+0x1bf/0x3c0 kthread+0xd7/0x100 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 -> #0 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}: __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 __flush_work+0x7a/0x4e0 __cancel_work_timer+0x131/0x1c0 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1a1/0x270 netlink_sendmsg+0x214/0x460 __sock_sendmsg+0x38/0x60 __sys_sendto+0x113/0x170 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x46/0x4e other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work)); lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work)); *** DEADLOCK *** 3 locks held by ethtool/386089: #0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40 #1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240 #2: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core] stack backtrace: CPU: 15 PID: 386089 Comm: ethtool Tainted: G I 6.7.0-rc4_net_next_mlx5_5483eb2 #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+0x60/0xa0 check_noncircular+0x144/0x160 __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 ? __flush_work+0x74/0x4e0 ? save_trace+0x3e/0x360 ? __flush_work+0x74/0x4e0 __flush_work+0x7a/0x4e0 ? __flush_work+0x74/0x4e0 ? • https://git.kernel.org/stable/c/45bf454ae88414e80b80979ebb2c22bd66ea7d1b https://git.kernel.org/stable/c/46efa4d5930cf3c2af8c01f75e0a47e4fc045e3b https://git.kernel.org/stable/c/48c4bb81df19402d4346032353d0795260255e3b https://git.kernel.org/stable/c/0080bf99499468030248ebd25dd645e487dcecdc https://git.kernel.org/stable/c/fef965764cf562f28afb997b626fc7c3cec99693 https://access.redhat.com/security/cve/CVE-2024-27014 https://bugzilla.redhat.com/show_bug.cgi?id=2278268 • CWE-667: Improper Locking •