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 ?
__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
—truncated—