CVE-2024-27014

一、漏洞信息
 漏洞编号：[CVE-2024-27014](https://nvd.nist.gov/vuln/detail/CVE-2024-27014)
 漏洞归属组件：[kernel](https://gitee.com/src-openeuler/kernel)
 漏洞归属的版本：4.19.140,4.19.194,4.19.90,5.10.0,6.1.0,6.1.14,6.1.19,6.1.5,6.1.6,6.1.8,6.4.0,6.6.0
 CVSS V3.0分值：
  BaseScore：5.5 Medium
  Vector：CVSS：3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
 漏洞简述：
  In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Prevent deadlock while disabling aRFSWhen disabling aRFS under the `priv->state_lock`, any scheduledaRFS 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 willtry to acquire the `state_lock` which is already acquired.The worker acquires the lock to delete the rules if the stateis down, which is not the worker s responsibility sincedisabling aRFS deletes the rules.Add an aRFS state variable, which indicates whether the aRFS isenabled and prevent adding rules when the aRFS is disabled.Kernel log:======================================================WARNING: possible circular locking dependency detected6.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/0x4e0but 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/0x4eother 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 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014Call 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---
 漏洞公开时间：2024-05-01 14:15:20
 漏洞创建时间：2024-05-08 00:43:45
 漏洞详情参考链接：
  https://nvd.nist.gov/vuln/detail/CVE-2024-27014
<details>
<summary>更多参考(点击展开)</summary>

| 参考来源 | 参考链接 | 来源链接 |
| ------- | -------- | -------- |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/0080bf99499468030248ebd25dd645e487dcecdc |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/46efa4d5930cf3c2af8c01f75e0a47e4fc045e3b |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/48c4bb81df19402d4346032353d0795260255e3b |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/fef965764cf562f28afb997b626fc7c3cec99693 |  |
| suse_bugzilla | http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-27014 | https://bugzilla.suse.com/show_bug.cgi?id=1223735 |
| suse_bugzilla | https://www.cve.org/CVERecord?id=CVE-2024-27014 | https://bugzilla.suse.com/show_bug.cgi?id=1223735 |
| suse_bugzilla | https://git.kernel.org/stable/c/0080bf99499468030248ebd25dd645e487dcecdc | https://bugzilla.suse.com/show_bug.cgi?id=1223735 |
| suse_bugzilla | https://git.kernel.org/stable/c/46efa4d5930cf3c2af8c01f75e0a47e4fc045e3b | https://bugzilla.suse.com/show_bug.cgi?id=1223735 |
| suse_bugzilla | https://git.kernel.org/stable/c/48c4bb81df19402d4346032353d0795260255e3b | https://bugzilla.suse.com/show_bug.cgi?id=1223735 |
| suse_bugzilla | https://git.kernel.org/stable/c/fef965764cf562f28afb997b626fc7c3cec99693 | https://bugzilla.suse.com/show_bug.cgi?id=1223735 |
| suse_bugzilla | https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2024/CVE-2024-27014.mbox | https://bugzilla.suse.com/show_bug.cgi?id=1223735 |
| suse_bugzilla | https://bugzilla.redhat.com/show_bug.cgi?id=2278268 | https://bugzilla.suse.com/show_bug.cgi?id=1223735 |
| redhat_bugzilla | https://lore.kernel.org/linux-cve-announce/2024050149-CVE-2024-27014-d2dc@gregkh/T | https://bugzilla.redhat.com/show_bug.cgi?id=2278268 |
| redhat_bugzilla | https://access.redhat.com/errata/RHSA-2024:3618 | https://bugzilla.redhat.com/show_bug.cgi?id=2278268 |
| redhat_bugzilla | https://access.redhat.com/errata/RHSA-2024:3627 | https://bugzilla.redhat.com/show_bug.cgi?id=2278268 |
| ubuntu | https://www.cve.org/CVERecord?id=CVE-2024-27014 | https://ubuntu.com/security/CVE-2024-27014 |
| ubuntu | https://git.kernel.org/linus/fef965764cf562f28afb997b626fc7c3cec99693 (6.9-rc5) | https://ubuntu.com/security/CVE-2024-27014 |
| ubuntu | https://git.kernel.org/stable/c/46efa4d5930cf3c2af8c01f75e0a47e4fc045e3b | https://ubuntu.com/security/CVE-2024-27014 |
| ubuntu | https://git.kernel.org/stable/c/48c4bb81df19402d4346032353d0795260255e3b | https://ubuntu.com/security/CVE-2024-27014 |
| ubuntu | https://git.kernel.org/stable/c/0080bf99499468030248ebd25dd645e487dcecdc | https://ubuntu.com/security/CVE-2024-27014 |
| ubuntu | https://git.kernel.org/stable/c/fef965764cf562f28afb997b626fc7c3cec99693 | https://ubuntu.com/security/CVE-2024-27014 |
| ubuntu | https://nvd.nist.gov/vuln/detail/CVE-2024-27014 | https://ubuntu.com/security/CVE-2024-27014 |
| ubuntu | https://launchpad.net/bugs/cve/CVE-2024-27014 | https://ubuntu.com/security/CVE-2024-27014 |
| ubuntu | https://security-tracker.debian.org/tracker/CVE-2024-27014 | https://ubuntu.com/security/CVE-2024-27014 |
| debian |  | https://security-tracker.debian.org/tracker/CVE-2024-27014 |
| anolis |  | https://anas.openanolis.cn/cves/detail/CVE-2024-27014 |
| cve_search |  | https://git.kernel.org/stable/c/46efa4d5930cf3c2af8c01f75e0a47e4fc045e3b |
| cve_search |  | https://git.kernel.org/stable/c/48c4bb81df19402d4346032353d0795260255e3b |
| cve_search |  | https://git.kernel.org/stable/c/0080bf99499468030248ebd25dd645e487dcecdc |
| cve_search |  | https://git.kernel.org/stable/c/fef965764cf562f28afb997b626fc7c3cec99693 |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/0080bf99499468030248ebd25dd645e487dcecdc |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/46efa4d5930cf3c2af8c01f75e0a47e4fc045e3b |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/48c4bb81df19402d4346032353d0795260255e3b |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/fef965764cf562f28afb997b626fc7c3cec99693 |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/ |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/ |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/ |  |

</details>

漏洞分析指导链接：
  https://gitee.com/openeuler/cve-manager/blob/master/cve-vulner-manager/doc/md/manual.md
 漏洞数据来源:
  openBrain开源漏洞感知系统
 漏洞补丁信息：
  <details>
<summary>详情(点击展开)</summary>

| 影响的包 | 修复版本 | 修复补丁 | 问题引入补丁 | 来源  |
| ------- | -------- | ------- | -------- | --------- |
|  |  | https://git.kernel.org/stable/c/0080bf99499468030248ebd25dd645e487dcecdc |  | nvd |
|  |  | https://git.kernel.org/stable/c/46efa4d5930cf3c2af8c01f75e0a47e4fc045e3b |  | nvd |
|  |  | https://git.kernel.org/stable/c/48c4bb81df19402d4346032353d0795260255e3b |  | nvd |
|  |  | https://git.kernel.org/stable/c/fef965764cf562f28afb997b626fc7c3cec99693 |  | nvd |
| linux |  | https://git.kernel.org/linus/fef965764cf562f28afb997b626fc7c3cec99693 | https://git.kernel.org/linus/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | ubuntu |

</details>

二、漏洞分析结构反馈
 影响性分析说明：
      In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Prevent deadlock while disabling aRFSWhen disabling aRFS under the `priv->state_lock`, any scheduledaRFS 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 willtry to acquire the `state_lock` which is already acquired.The worker acquires the lock to delete the rules if the stateis down, which is not the worker s responsibility sincedisabling aRFS deletes the rules.Add an aRFS state variable, which indicates whether the aRFS isenabled and prevent adding rules when the aRFS is disabled.Kernel log:======================================================WARNING: possible circular locking dependency detected6.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/0x4e0but 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/0x4eother 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 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014Call 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---  
 openEuler评分：
  5.5
 Vector：CVSS：3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
 受影响版本排查(受影响/不受影响)：
  1.openEuler-20.03-LTS-SP4(4.19.90):受影响
2.openEuler-22.03-LTS-SP1(5.10.0):受影响
3.openEuler-22.03-LTS-SP3(5.10.0):受影响
4.openEuler-22.03-LTS-SP4(5.10.0):不受影响
5.master(6.1.0):不受影响
6.openEuler-24.03-LTS(6.6.0):不受影响
7.openEuler-24.03-LTS-Next(6.6.0):不受影响

修复是否涉及abi变化(是/否)：
  1.openEuler-20.03-LTS-SP4(4.19.90):否
2.openEuler-22.03-LTS-SP1(5.10.0):否
3.openEuler-22.03-LTS-SP3(5.10.0):否
4.master(6.1.0):否
5.openEuler-24.03-LTS(6.6.0):否
6.openEuler-24.03-LTS-Next(6.6.0):否
7.openEuler-22.03-LTS-SP4(5.10.0):否

三、漏洞修复
安全公告链接：https://www.openeuler.org/zh/security/safety-bulletin/detail/?id=openEuler-SA-2024-1738

@yangyingliang ,@jiaoff ,@guohaocs2c ,@hanjun-guo ,@woqidaideshi ,@newbeats ,@zhangyi089 ,@colyli ,@thundertown ,@htforge ,@chiqijun ,@lengchao ,@zhujianwei001 ,@kylin-mayukun ,@wangxiongfeng ,@wkfxxx ,@SuperSix173 ,@jentlestea ,@oskernel0719 ,@gasonchen 
**issue处理注意事项:** 
**1. 当前issue受影响的分支提交pr时, 须在pr描述中填写当前issue编号进行关联, 否则无法关闭当前issue;**
**2. 模板内容需要填写完整, 无论是受影响或者不受影响都需要填写完整内容,未引入的分支不需要填写, 否则无法关闭当前issue;**
**3. 以下为模板中需要填写完整的内容, 请复制到评论区回复, 注: 内容的标题名称(影响性分析说明, openEuler评分, 受影响版本排查(受影响/不受影响), 修复是否涉及abi变化(是/否))不能省略,省略后cve-manager将无法正常解析填写内容.**
************************************************************************
影响性分析说明:

openEuler评分: (评分和向量)

受影响版本排查(受影响/不受影响): 
1.master(6.1.0):
2.openEuler-20.03-LTS-SP1(4.19.90):
3.openEuler-20.03-LTS-SP4(4.19.90):
4.openEuler-22.03-LTS(5.10.0):
5.openEuler-22.03-LTS-Next(5.10.0):
6.openEuler-22.03-LTS-SP1(5.10.0):
7.openEuler-22.03-LTS-SP2(5.10.0):
8.openEuler-22.03-LTS-SP3(5.10.0):
9.openEuler-24.03-LTS:
10.openEuler-24.03-LTS-Next:

修复是否涉及abi变化(是/否)：
1.master(6.1.0):
2.openEuler-20.03-LTS-SP1(4.19.90):
3.openEuler-20.03-LTS-SP4(4.19.90):
4.openEuler-22.03-LTS(5.10.0):
5.openEuler-22.03-LTS-Next(5.10.0):
6.openEuler-22.03-LTS-SP1(5.10.0):
7.openEuler-22.03-LTS-SP2(5.10.0):
8.openEuler-22.03-LTS-SP3(5.10.0):
9.openEuler-24.03-LTS:
10.openEuler-24.03-LTS-Next:

-----------------------------------------------------------------------
issue处理具体操作请参考: 
https://gitee.com/openeuler/cve-manager/blob/master/cve-vulner-manager/doc/md/manual.md
pr关联issue具体操作请参考:
https://gitee.com/help/articles/4142

<table><tr><th white-space: nowrap;>参考网址</th> <th white-space: nowrap;>关联pr</th> <th white-space: nowrap;>状态</th> <th white-space: nowrap;>补丁链接</th></tr><tr><td rowspan="1">https://nvd.nist.gov/vuln/detail/CVE-2024-27014</td><td>None</td><td>None</td><td><a href=https://git.kernel.org/stable/c/46efa4d5930cf3c2af8c01f75e0a47e4fc045e3b>https://git.kernel.org/stable/c/46efa4d5930cf3c2af8c01f75e0a47e4fc045e3b</a><br /><a href=https://git.kernel.org/stable/c/0080bf99499468030248ebd25dd645e487dcecdc>https://git.kernel.org/stable/c/0080bf99499468030248ebd25dd645e487dcecdc</a><br /><a href=https://git.kernel.org/stable/c/48c4bb81df19402d4346032353d0795260255e3b>https://git.kernel.org/stable/c/48c4bb81df19402d4346032353d0795260255e3b</a><br /><a href=https://git.kernel.org/stable/c/fef965764cf562f28afb997b626fc7c3cec99693>https://git.kernel.org/stable/c/fef965764cf562f28afb997b626fc7c3cec99693</a></td></tr><tr><td rowspan="1">https://www.opencve.io/cve/CVE-2024-27014</td><td>None</td><td>None</td><td><a href=https://git.kernel.org/stable/c/46efa4d5930cf3c2af8c01f75e0a47e4fc045e3b>https://git.kernel.org/stable/c/46efa4d5930cf3c2af8c01f75e0a47e4fc045e3b</a><br /><a href=https://git.kernel.org/stable/c/0080bf99499468030248ebd25dd645e487dcecdc>https://git.kernel.org/stable/c/0080bf99499468030248ebd25dd645e487dcecdc</a><br /><a href=https://git.kernel.org/stable/c/48c4bb81df19402d4346032353d0795260255e3b>https://git.kernel.org/stable/c/48c4bb81df19402d4346032353d0795260255e3b</a><br /><a href=https://git.kernel.org/stable/c/fef965764cf562f28afb997b626fc7c3cec99693>https://git.kernel.org/stable/c/fef965764cf562f28afb997b626fc7c3cec99693</a></td></tr><tr><td>https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2024-27014</td><td></td><td></td><td></td></tr><tr><td rowspan="1">https://security-tracker.debian.org/tracker/CVE-2024-27014</td><td>None</td><td>None</td><td><a href=https://git.kernel.org/linus/fef965764cf562f28afb997b626fc7c3cec99693>https://git.kernel.org/linus/fef965764cf562f28afb997b626fc7c3cec99693</a></td></tr></table>

> 说明：补丁链接仅供初步排查参考，实际可用性请人工再次确认，补丁下载验证可使用[CVE补丁工具](https://gitee.com/openeuler/cve-manager/blob/master/cve-agency-manager/cve_tracking/README.md)。
若补丁不准确，烦请在此issue下评论 '/report-patch 参考网址 补丁链接1,补丁链接2' 反馈正确信息，便于我们不断优化工具，不胜感激。
如 /report-patch https://security-tracker.debian.org/tracker/CVE-2021-3997 https://github.com/systemd/systemd/commit/5b1cf7a9be37e20133c0208005274ce4a5b5c6a1

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---

openEuler评分:(评分和向量)
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

受影响版本排查(受影响/不受影响):
1.openEuler-20.03-LTS-SP4:受影响
2.openEuler-22.03-LTS-SP1:受影响
3.openEuler-22.03-LTS-SP3:受影响
4.openEuler-22.03-LTS-SP4:不受影响
5.master(6.1.0):不受影响
6.openEuler-24.03-LTS:不受影响
7.openEuler-24.03-LTS-Next:不受影响

修复是否涉及abi变化(是/否)：
1.openEuler-20.03-LTS-SP4:否
2.openEuler-22.03-LTS-SP1:否
3.openEuler-22.03-LTS-SP3:否
4.master(6.1.0):否
5.openEuler-24.03-LTS:否
6.openEuler-24.03-LTS-Next:否
7.openEuler-22.03-LTS-SP4:否

===========================================================

@sanglipeng 经过 cve-manager 解析, 已分析的内容如下表所示:
| 状态  | 需分析 | 内容 |
|:--:|:--:|---------|
|已分析|1.影响性分析说明|In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Prevent deadlock while disabling aRFSWhen disabling aRFS under the `priv->state_lock`, any scheduledaRFS 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 willtry to acquire the `state_lock` which is already acquired.The worker acquires the lock to delete the rules if the stateis down, which is not the worker's responsibility sincedisabling aRFS deletes the rules.Add an aRFS state variable, which indicates whether the aRFS isenabled and prevent adding rules when the aRFS is disabled.Kernel log:======================================================WARNING: possible circular locking dependency detected6.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/0x4e0but 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/0x4eother 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 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014Call 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---|
|已分析|2.openEulerScore|5.5|
|已分析|3.openEulerVector|AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H|
|已分析|4.受影响版本排查|openEuler-20.03-LTS-SP4:受影响,openEuler-22.03-LTS-SP1:受影响,openEuler-22.03-LTS-SP3:受影响,openEuler-22.03-LTS-SP4:不受影响,master:不受影响,openEuler-24.03-LTS:不受影响,openEuler-24.03-LTS-Next:不受影响|
|已分析|5.修复是否涉及abi变化|openEuler-20.03-LTS-SP4:否,openEuler-22.03-LTS-SP1:否,openEuler-22.03-LTS-SP3:否,master:否,openEuler-24.03-LTS:否,openEuler-24.03-LTS-Next:否,openEuler-22.03-LTS-SP4:否|

**请确认分析内容的准确性, 确认无误后, 您可以进行后续步骤, 否则您可以继续分析.**

src-openEuler/kernel

内容风险标识

评论 (13)

src-openEuler/kernel .gitee-modal { width: 500px !important; }

内容风险标识

CVE-2024-27014

评论 (13)

搜索帮助

src-openEuler/kernel