CVE-2024-46678

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bonding: change ipsec_lock from spin lock to mutex<br /> <br /> In the cited commit, bond-&gt;ipsec_lock is added to protect ipsec_list,<br /> hence xdo_dev_state_add and xdo_dev_state_delete are called inside<br /> this lock. As ipsec_lock is a spin lock and such xfrmdev ops may sleep,<br /> "scheduling while atomic" will be triggered when changing bond&amp;#39;s<br /> active slave.<br /> <br /> [ 101.055189] BUG: scheduling while atomic: bash/902/0x00000200<br /> [ 101.055726] Modules linked in:<br /> [ 101.058211] CPU: 3 PID: 902 Comm: bash Not tainted 6.9.0-rc4+ #1<br /> [ 101.058760] Hardware name:<br /> [ 101.059434] Call Trace:<br /> [ 101.059436] <br /> [ 101.060873] dump_stack_lvl+0x51/0x60<br /> [ 101.061275] __schedule_bug+0x4e/0x60<br /> [ 101.061682] __schedule+0x612/0x7c0<br /> [ 101.062078] ? __mod_timer+0x25c/0x370<br /> [ 101.062486] schedule+0x25/0xd0<br /> [ 101.062845] schedule_timeout+0x77/0xf0<br /> [ 101.063265] ? asm_common_interrupt+0x22/0x40<br /> [ 101.063724] ? __bpf_trace_itimer_state+0x10/0x10<br /> [ 101.064215] __wait_for_common+0x87/0x190<br /> [ 101.064648] ? usleep_range_state+0x90/0x90<br /> [ 101.065091] cmd_exec+0x437/0xb20 [mlx5_core]<br /> [ 101.065569] mlx5_cmd_do+0x1e/0x40 [mlx5_core]<br /> [ 101.066051] mlx5_cmd_exec+0x18/0x30 [mlx5_core]<br /> [ 101.066552] mlx5_crypto_create_dek_key+0xea/0x120 [mlx5_core]<br /> [ 101.067163] ? bonding_sysfs_store_option+0x4d/0x80 [bonding]<br /> [ 101.067738] ? kmalloc_trace+0x4d/0x350<br /> [ 101.068156] mlx5_ipsec_create_sa_ctx+0x33/0x100 [mlx5_core]<br /> [ 101.068747] mlx5e_xfrm_add_state+0x47b/0xaa0 [mlx5_core]<br /> [ 101.069312] bond_change_active_slave+0x392/0x900 [bonding]<br /> [ 101.069868] bond_option_active_slave_set+0x1c2/0x240 [bonding]<br /> [ 101.070454] __bond_opt_set+0xa6/0x430 [bonding]<br /> [ 101.070935] __bond_opt_set_notify+0x2f/0x90 [bonding]<br /> [ 101.071453] bond_opt_tryset_rtnl+0x72/0xb0 [bonding]<br /> [ 101.071965] bonding_sysfs_store_option+0x4d/0x80 [bonding]<br /> [ 101.072567] kernfs_fop_write_iter+0x10c/0x1a0<br /> [ 101.073033] vfs_write+0x2d8/0x400<br /> [ 101.073416] ? alloc_fd+0x48/0x180<br /> [ 101.073798] ksys_write+0x5f/0xe0<br /> [ 101.074175] do_syscall_64+0x52/0x110<br /> [ 101.074576] entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> As bond_ipsec_add_sa_all and bond_ipsec_del_sa_all are only called<br /> from bond_change_active_slave, which requires holding the RTNL lock.<br /> And bond_ipsec_add_sa and bond_ipsec_del_sa are xfrm state<br /> xdo_dev_state_add and xdo_dev_state_delete APIs, which are in user<br /> context. So ipsec_lock doesn&amp;#39;t have to be spin lock, change it to<br /> mutex, and thus the above issue can be resolved.