GHSA-2MH2-9XM5-M59Q
Vulnerability from github – Published: 2024-09-13 06:30 – Updated: 2024-09-23 15:31In the Linux kernel, the following vulnerability has been resolved:
bonding: change ipsec_lock from spin lock to mutex
In the cited commit, bond->ipsec_lock is added to protect ipsec_list, hence xdo_dev_state_add and xdo_dev_state_delete are called inside this lock. As ipsec_lock is a spin lock and such xfrmdev ops may sleep, "scheduling while atomic" will be triggered when changing bond's active slave.
[ 101.055189] BUG: scheduling while atomic: bash/902/0x00000200 [ 101.055726] Modules linked in: [ 101.058211] CPU: 3 PID: 902 Comm: bash Not tainted 6.9.0-rc4+ #1 [ 101.058760] Hardware name: [ 101.059434] Call Trace: [ 101.059436] [ 101.060873] dump_stack_lvl+0x51/0x60 [ 101.061275] __schedule_bug+0x4e/0x60 [ 101.061682] __schedule+0x612/0x7c0 [ 101.062078] ? __mod_timer+0x25c/0x370 [ 101.062486] schedule+0x25/0xd0 [ 101.062845] schedule_timeout+0x77/0xf0 [ 101.063265] ? asm_common_interrupt+0x22/0x40 [ 101.063724] ? __bpf_trace_itimer_state+0x10/0x10 [ 101.064215] __wait_for_common+0x87/0x190 [ 101.064648] ? usleep_range_state+0x90/0x90 [ 101.065091] cmd_exec+0x437/0xb20 [mlx5_core] [ 101.065569] mlx5_cmd_do+0x1e/0x40 [mlx5_core] [ 101.066051] mlx5_cmd_exec+0x18/0x30 [mlx5_core] [ 101.066552] mlx5_crypto_create_dek_key+0xea/0x120 [mlx5_core] [ 101.067163] ? bonding_sysfs_store_option+0x4d/0x80 [bonding] [ 101.067738] ? kmalloc_trace+0x4d/0x350 [ 101.068156] mlx5_ipsec_create_sa_ctx+0x33/0x100 [mlx5_core] [ 101.068747] mlx5e_xfrm_add_state+0x47b/0xaa0 [mlx5_core] [ 101.069312] bond_change_active_slave+0x392/0x900 [bonding] [ 101.069868] bond_option_active_slave_set+0x1c2/0x240 [bonding] [ 101.070454] __bond_opt_set+0xa6/0x430 [bonding] [ 101.070935] __bond_opt_set_notify+0x2f/0x90 [bonding] [ 101.071453] bond_opt_tryset_rtnl+0x72/0xb0 [bonding] [ 101.071965] bonding_sysfs_store_option+0x4d/0x80 [bonding] [ 101.072567] kernfs_fop_write_iter+0x10c/0x1a0 [ 101.073033] vfs_write+0x2d8/0x400 [ 101.073416] ? alloc_fd+0x48/0x180 [ 101.073798] ksys_write+0x5f/0xe0 [ 101.074175] do_syscall_64+0x52/0x110 [ 101.074576] entry_SYSCALL_64_after_hwframe+0x4b/0x53
As bond_ipsec_add_sa_all and bond_ipsec_del_sa_all are only called from bond_change_active_slave, which requires holding the RTNL lock. And bond_ipsec_add_sa and bond_ipsec_del_sa are xfrm state xdo_dev_state_add and xdo_dev_state_delete APIs, which are in user context. So ipsec_lock doesn't have to be spin lock, change it to mutex, and thus the above issue can be resolved.
{
"affected": [],
"aliases": [
"CVE-2024-46678"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-13T06:15:12Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbonding: change ipsec_lock from spin lock to mutex\n\nIn the cited commit, bond-\u003eipsec_lock is added to protect ipsec_list,\nhence xdo_dev_state_add and xdo_dev_state_delete are called inside\nthis lock. As ipsec_lock is a spin lock and such xfrmdev ops may sleep,\n\"scheduling while atomic\" will be triggered when changing bond\u0027s\nactive slave.\n\n[ 101.055189] BUG: scheduling while atomic: bash/902/0x00000200\n[ 101.055726] Modules linked in:\n[ 101.058211] CPU: 3 PID: 902 Comm: bash Not tainted 6.9.0-rc4+ #1\n[ 101.058760] Hardware name:\n[ 101.059434] Call Trace:\n[ 101.059436] \u003cTASK\u003e\n[ 101.060873] dump_stack_lvl+0x51/0x60\n[ 101.061275] __schedule_bug+0x4e/0x60\n[ 101.061682] __schedule+0x612/0x7c0\n[ 101.062078] ? __mod_timer+0x25c/0x370\n[ 101.062486] schedule+0x25/0xd0\n[ 101.062845] schedule_timeout+0x77/0xf0\n[ 101.063265] ? asm_common_interrupt+0x22/0x40\n[ 101.063724] ? __bpf_trace_itimer_state+0x10/0x10\n[ 101.064215] __wait_for_common+0x87/0x190\n[ 101.064648] ? usleep_range_state+0x90/0x90\n[ 101.065091] cmd_exec+0x437/0xb20 [mlx5_core]\n[ 101.065569] mlx5_cmd_do+0x1e/0x40 [mlx5_core]\n[ 101.066051] mlx5_cmd_exec+0x18/0x30 [mlx5_core]\n[ 101.066552] mlx5_crypto_create_dek_key+0xea/0x120 [mlx5_core]\n[ 101.067163] ? bonding_sysfs_store_option+0x4d/0x80 [bonding]\n[ 101.067738] ? kmalloc_trace+0x4d/0x350\n[ 101.068156] mlx5_ipsec_create_sa_ctx+0x33/0x100 [mlx5_core]\n[ 101.068747] mlx5e_xfrm_add_state+0x47b/0xaa0 [mlx5_core]\n[ 101.069312] bond_change_active_slave+0x392/0x900 [bonding]\n[ 101.069868] bond_option_active_slave_set+0x1c2/0x240 [bonding]\n[ 101.070454] __bond_opt_set+0xa6/0x430 [bonding]\n[ 101.070935] __bond_opt_set_notify+0x2f/0x90 [bonding]\n[ 101.071453] bond_opt_tryset_rtnl+0x72/0xb0 [bonding]\n[ 101.071965] bonding_sysfs_store_option+0x4d/0x80 [bonding]\n[ 101.072567] kernfs_fop_write_iter+0x10c/0x1a0\n[ 101.073033] vfs_write+0x2d8/0x400\n[ 101.073416] ? alloc_fd+0x48/0x180\n[ 101.073798] ksys_write+0x5f/0xe0\n[ 101.074175] do_syscall_64+0x52/0x110\n[ 101.074576] entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nAs bond_ipsec_add_sa_all and bond_ipsec_del_sa_all are only called\nfrom bond_change_active_slave, which requires holding the RTNL lock.\nAnd bond_ipsec_add_sa and bond_ipsec_del_sa are xfrm state\nxdo_dev_state_add and xdo_dev_state_delete APIs, which are in user\ncontext. So ipsec_lock doesn\u0027t have to be spin lock, change it to\nmutex, and thus the above issue can be resolved.",
"id": "GHSA-2mh2-9xm5-m59q",
"modified": "2024-09-23T15:31:00Z",
"published": "2024-09-13T06:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46678"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2aeeef906d5a526dc60cf4af92eda69836c39b1f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/56354b0a2c24a7828eeed7de4b4dc9652d9affa3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6b598069164ac1bb60996d6ff94e7f9169dbd2d3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.