Vulnerabilidad en kernel de Linux (CVE-2024-27014)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: evita el interbloqueo al deshabilitar aRFS. Al deshabilitar aRFS bajo `priv->state_lock`, cualquier trabajo de aRFS programado se cancela usando la función `cancel_work_sync`, que espera la trabajo para terminar si ya ha comenzado. Sin embargo, mientras espera el controlador de trabajo, el controlador intentará adquirir el `state_lock` que ya está adquirido. El trabajador adquiere el bloqueo para eliminar las reglas si el estado está inactivo, lo cual no es responsabilidad del trabajador ya que al desactivar aRFS se eliminan las reglas. Agregue una variable de estado de aRFS, que indica si aRFS está habilitado y evita agregar reglas cuando aRFS está deshabilitado. Registro del kernel: ================================================= ======= ADVERTENCIA: posible dependencia de bloqueo circular detectada 6.7.0-rc4_net_next_mlx5_5483eb2 #1 Contaminado: GI -------------------- ---------------------- ethtool/386089 está intentando adquirir el bloqueo: ffff88810f21ce68 ((work_completion)(&rule->arfs_work)){ +.+.}-{0:0}, en: __flush_work+0x74/0x4e0 pero la tarea ya mantiene el bloqueo: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, en: mlx5e_ethtool_set_channels+ 0x53/0x200 [mlx5_core] cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es: -> #1 (&priv->state_lock){+.+.}-{3:3}: __mutex_lock+0x80/0xc90 arfs_handle_work+0x4b/0x3b0 [mlx5_core] Process_one_work+0x1dc /0x4a0 work_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/0 x460 __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 otra información que podría ayudarnos a depurar esto: Posible escenario de bloqueo inseguro: CPU0 CPU1 ---- ---- lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work)); bloquear(&priv->state_lock); lock((work_completion)(&rule->arfs_work)); *** DEADLOCK *** 3 bloqueos retenidos por ethtool/386089: #0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, en: genl_rcv+0x15/0x40 #1: ffffffff82e94c88 (rtnl_mutex){ +.+.}-{3:3}, en: ethnl_default_set_doit+0xd3/0x240 #2: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, en: mlx5e_ethtool_set_channels+0x53/0x200 [ mlx5_core] seguimiento de pila: CPU: 15 PID: 386089 Comm: ethtool Tainted: GI 6.7.0-rc4_net_next_mlx5_5483eb2 #1 Nombre de hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt .qemu.org 01/04/2014 Seguimiento de llamadas: 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? __lock_acquire+0xa78/0x2c80? lock_acquire+0xd0/0x2b0? mark_held_locks+0x49/0x70 __cancel_work_timer+0x131/0x1c0 ? mark_held_locks+0x49/0x70 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 ? ethn ---truncado---