CVE-2022-49215

一、漏洞信息
 漏洞编号：[CVE-2022-49215](https://nvd.nist.gov/vuln/detail/CVE-2022-49215)
 漏洞归属组件：[kernel](https://gitee.com/src-openeuler/kernel)
 漏洞归属的版本：4.19.140,4.19.194,4.19.90,5.10.0,6.1.19,6.4.0,6.6.0
 CVSS V3.0分值：
  BaseScore：4.7 Medium
  Vector：CVSS：3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
 漏洞简述：
  In the Linux kernel, the following vulnerability has been resolved:xsk: Fix race at socket teardownFix a race in the xsk socket teardown code that can lead to a NULL pointerdereference splat. The current xsk unbind code in xsk_unbind_dev() starts bysetting xs->state to XSK_UNBOUND, sets xs->dev to NULL and then waits for anyNAPI processing to terminate using synchronize_net(). After that, the releasecode starts to tear down the socket state and free allocated memory.  BUG: kernel NULL pointer dereference, address: 00000000000000c0  PGD 8000000932469067 P4D 8000000932469067 PUD 0  Oops: 0000 [#1] PREEMPT SMP PTI  CPU: 25 PID: 69132 Comm: grpcpp_sync_ser Tainted: G          I       5.16.0+ #2  Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.2.10 03/09/2015  RIP: 0010:__xsk_sendmsg+0x2c/0x690  [...]  RSP: 0018:ffffa2348bd13d50 EFLAGS: 00010246  RAX: 0000000000000000 RBX: 0000000000000040 RCX: ffff8d5fc632d258  RDX: 0000000000400000 RSI: ffffa2348bd13e10 RDI: ffff8d5fc5489800  RBP: ffffa2348bd13db0 R08: 0000000000000000 R09: 00007ffffffff000  R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d5fc5489800  R13: ffff8d5fcb0f5140 R14: ffff8d5fcb0f5140 R15: 0000000000000000  FS:  00007f991cff9400(0000) GS:ffff8d6f1f700000(0000) knlGS:0000000000000000  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: 00000000000000c0 CR3: 0000000114888005 CR4: 00000000001706e0  Call Trace:  <TASK>  ? aa_sk_perm+0x43/0x1b0  xsk_sendmsg+0xf0/0x110  sock_sendmsg+0x65/0x70  __sys_sendto+0x113/0x190  ? debug_smp_processor_id+0x17/0x20  ? fpregs_assert_state_consistent+0x23/0x50  ? exit_to_user_mode_prepare+0xa5/0x1d0  __x64_sys_sendto+0x29/0x30  do_syscall_64+0x3b/0xc0  entry_SYSCALL_64_after_hwframe+0x44/0xaeThere are two problems with the current code. First, setting xs->dev to NULLbefore waiting for all users to stop using the socket is not correct. Theentry to the data plane functions xsk_poll(), xsk_sendmsg(), and xsk_recvmsg()are all guarded by a test that xs->state is in the state XSK_BOUND and if not,it returns right away. But one process might have passed this test but stillhave not gotten to the point in which it uses xs->dev in the code. In thisinterim, a second process executing xsk_unbind_dev() might have set xs->dev toNULL which will lead to a crash for the first process. The solution here isjust to get rid of this NULL assignment since it is not used anymore. Beforecommit 42fddcc7c64b ( xsk: use state member for socket synchronization ),xs->dev was the gatekeeper to admit processes into the data plane functions,but it was replaced with the state variable xs->state in the aforementionedcommit.The second problem is that synchronize_net() does not wait for any process inxsk_poll(), xsk_sendmsg(), or xsk_recvmsg() to complete, which means that thestate they rely on might be cleaned up prematurely. This can happen when thenotifier gets called (at driver unload for example) as it uses xsk_unbind_dev().Solve this by extending the RCU critical region from just the ndo_xsk_wakeupto the whole functions mentioned above, so that both the test of xs->state ==XSK_BOUND and the last use of any member of xs is covered by the RCU criticalsection. This will guarantee that when synchronize_net() completes, there willbe no processes left executing xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() andstate can be cleaned up safely. Note that we need to drop the RCU lock for theskb xmit path as it uses functions that might sleep. Due to this, we have toretest the xs->state after we grab the mutex that protects the skb xmit codefrom, among a number of things, an xsk_unbind_dev() being executed from thenotifier at the same time.
 漏洞公开时间：2025-02-26 15:00:58
 漏洞创建时间：2025-02-26 18:45:56
 漏洞详情参考链接：
  https://nvd.nist.gov/vuln/detail/CVE-2022-49215
<details>
<summary>更多参考(点击展开)</summary>

| 参考来源 | 参考链接 | 来源链接 |
| ------- | -------- | -------- |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/18b1ab7aa76bde181bdb1ab19a87fa9523c32f21 |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/8a2dea162b92c322f3e42eae0c4a74b8d20aa7a9 |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/ad7219cd8751bd258b9d1e69ae0654ec00f71875 |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/d1579253ffce39986e7a6ab757ac93b2680a665f |  |
| suse_bugzilla | http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-49215 | https://bugzilla.suse.com/show_bug.cgi?id=1238329 |
| suse_bugzilla | https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2022/CVE-2022-49215.mbox | https://bugzilla.suse.com/show_bug.cgi?id=1238329 |
| suse_bugzilla | https://git.kernel.org/stable/c/ad7219cd8751bd258b9d1e69ae0654ec00f71875 | https://bugzilla.suse.com/show_bug.cgi?id=1238329 |
| suse_bugzilla | https://git.kernel.org/stable/c/d1579253ffce39986e7a6ab757ac93b2680a665f | https://bugzilla.suse.com/show_bug.cgi?id=1238329 |
| suse_bugzilla | https://git.kernel.org/stable/c/8a2dea162b92c322f3e42eae0c4a74b8d20aa7a9 | https://bugzilla.suse.com/show_bug.cgi?id=1238329 |
| suse_bugzilla | https://git.kernel.org/stable/c/18b1ab7aa76bde181bdb1ab19a87fa9523c32f21 | https://bugzilla.suse.com/show_bug.cgi?id=1238329 |
| suse_bugzilla | https://bugzilla.redhat.com/show_bug.cgi?id=2347654 | https://bugzilla.suse.com/show_bug.cgi?id=1238329 |
| redhat_bugzilla | https://lore.kernel.org/linux-cve-announce/2025022620-CVE-2022-49215-8328@gregkh/T | https://bugzilla.redhat.com/show_bug.cgi?id=2347654 |

</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/18b1ab7aa76bde181bdb1ab19a87fa9523c32f21 |  | nvd |
|  |  | https://git.kernel.org/stable/c/8a2dea162b92c322f3e42eae0c4a74b8d20aa7a9 |  | nvd |
|  |  | https://git.kernel.org/stable/c/ad7219cd8751bd258b9d1e69ae0654ec00f71875 |  | nvd |
|  |  | https://git.kernel.org/stable/c/d1579253ffce39986e7a6ab757ac93b2680a665f |  | nvd |

</details>

二、漏洞分析结构反馈
 影响性分析说明：
  In the Linux kernel, the following vulnerability has been resolved:xsk: Fix race at socket teardownFix a race in the xsk socket teardown code that can lead to a NULL pointerdereference splat. The current xsk unbind code in xsk_unbind_dev() starts bysetting xs->state to XSK_UNBOUND, sets xs->dev to NULL and then waits for anyNAPI processing to terminate using synchronize_net(). After that, the releasecode starts to tear down the socket state and free allocated memory.  BUG: kernel NULL pointer dereference, address: 00000000000000c0  PGD 8000000932469067 P4D 8000000932469067 PUD 0  Oops: 0000 [#1] PREEMPT SMP PTI  CPU: 25 PID: 69132 Comm: grpcpp_sync_ser Tainted: G          I       5.16.0+ #2  Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.2.10 03/09/2015  RIP: 0010:__xsk_sendmsg+0x2c/0x690  [...]  RSP: 0018:ffffa2348bd13d50 EFLAGS: 00010246  RAX: 0000000000000000 RBX: 0000000000000040 RCX: ffff8d5fc632d258  RDX: 0000000000400000 RSI: ffffa2348bd13e10 RDI: ffff8d5fc5489800  RBP: ffffa2348bd13db0 R08: 0000000000000000 R09: 00007ffffffff000  R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d5fc5489800  R13: ffff8d5fcb0f5140 R14: ffff8d5fcb0f5140 R15: 0000000000000000  FS:  00007f991cff9400(0000) GS:ffff8d6f1f700000(0000) knlGS:0000000000000000  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: 00000000000000c0 CR3: 0000000114888005 CR4: 00000000001706e0  Call Trace:  <TASK>  ? aa_sk_perm+0x43/0x1b0  xsk_sendmsg+0xf0/0x110  sock_sendmsg+0x65/0x70  __sys_sendto+0x113/0x190  ? debug_smp_processor_id+0x17/0x20  ? fpregs_assert_state_consistent+0x23/0x50  ? exit_to_user_mode_prepare+0xa5/0x1d0  __x64_sys_sendto+0x29/0x30  do_syscall_64+0x3b/0xc0  entry_SYSCALL_64_after_hwframe+0x44/0xaeThere are two problems with the current code. First, setting xs->dev to NULLbefore waiting for all users to stop using the socket is not correct. Theentry to the data plane functions xsk_poll(), xsk_sendmsg(), and xsk_recvmsg()are all guarded by a test that xs->state is in the state XSK_BOUND and if not,it returns right away. But one process might have passed this test but stillhave not gotten to the point in which it uses xs->dev in the code. In thisinterim, a second process executing xsk_unbind_dev() might have set xs->dev toNULL which will lead to a crash for the first process. The solution here isjust to get rid of this NULL assignment since it is not used anymore. Beforecommit 42fddcc7c64b ( xsk: use state member for socket synchronization ),xs->dev was the gatekeeper to admit processes into the data plane functions,but it was replaced with the state variable xs->state in the aforementionedcommit.The second problem is that synchronize_net() does not wait for any process inxsk_poll(), xsk_sendmsg(), or xsk_recvmsg() to complete, which means that thestate they rely on might be cleaned up prematurely. This can happen when thenotifier gets called (at driver unload for example) as it uses xsk_unbind_dev().Solve this by extending the RCU critical region from just the ndo_xsk_wakeupto the whole functions mentioned above, so that both the test of xs->state ==XSK_BOUND and the last use of any member of xs is covered by the RCU criticalsection. This will guarantee that when synchronize_net() completes, there willbe no processes left executing xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() andstate can be cleaned up safely. Note that we need to drop the RCU lock for theskb xmit path as it uses functions that might sleep. Due to this, we have toretest the xs->state after we grab the mutex that protects the skb xmit codefrom, among a number of things, an xsk_unbind_dev() being executed from thenotifier at the same time.
 openEuler评分：
  4.7
 Vector：CVSS：3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
 受影响版本排查(受影响/不受影响)：
  1.openEuler-22.03-LTS-SP3(5.10.0):受影响
2.openEuler-22.03-LTS-SP4(5.10.0):受影响
3.openEuler-20.03-LTS-SP4(4.19.90):不受影响
4.master(6.6.0):不受影响
5.openEuler-24.03-LTS(6.6.0):不受影响
6.openEuler-24.03-LTS-Next(6.6.0):不受影响
7.openEuler-24.03-LTS-SP1(6.6.0):不受影响

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

原因说明：
  1.openEuler-22.03-LTS-SP3(5.10.0):不修复-超出修复范围
2.openEuler-22.03-LTS-SP4(5.10.0):不修复-超出修复范围
3.master(6.6.0):不受影响-漏洞代码不能被攻击者触发
4.openEuler-24.03-LTS-Next(6.6.0):不受影响-漏洞代码不能被攻击者触发
5.openEuler-20.03-LTS-SP4(4.19.90):不受影响-漏洞代码不存在
6.openEuler-24.03-LTS(6.6.0):不受影响-漏洞代码不存在
7.openEuler-24.03-LTS-SP1(6.6.0):不受影响-漏洞代码不存在

src-openEuler/kernel

内容风险标识

评论 (6)

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

内容风险标识

CVE-2022-49215

评论 (6)

搜索帮助

src-openEuler/kernel