CVE-2022-49898

一、漏洞信息
 漏洞编号：[CVE-2022-49898](https://nvd.nist.gov/vuln/detail/CVE-2022-49898)
 漏洞归属组件：[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：N/A None
  Vector：CVSS：3.0/
 漏洞简述：
  In the Linux kernel, the following vulnerability has been resolved:btrfs: fix tree mod log mishandling of reallocated nodesWe have been seeing the following panic in production  kernel BUG at fs/btrfs/tree-mod-log.c:677!  invalid opcode: 0000 [#1] SMP  RIP: 0010:tree_mod_log_rewind+0x1b4/0x200  RSP: 0000:ffffc9002c02f890 EFLAGS: 00010293  RAX: 0000000000000003 RBX: ffff8882b448c700 RCX: 0000000000000000  RDX: 0000000000008000 RSI: 00000000000000a7 RDI: ffff88877d831c00  RBP: 0000000000000002 R08: 000000000000009f R09: 0000000000000000  R10: 0000000000000000 R11: 0000000000100c40 R12: 0000000000000001  R13: ffff8886c26d6a00 R14: ffff88829f5424f8 R15: ffff88877d831a00  FS:  00007fee1d80c780(0000) GS:ffff8890400c0000(0000) knlGS:0000000000000000  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: 00007fee1963a020 CR3: 0000000434f33002 CR4: 00000000007706e0  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400  PKRU: 55555554  Call Trace:   btrfs_get_old_root+0x12b/0x420   btrfs_search_old_slot+0x64/0x2f0   ? tree_mod_log_oldest_root+0x3d/0xf0   resolve_indirect_ref+0xfd/0x660   ? ulist_alloc+0x31/0x60   ? kmem_cache_alloc_trace+0x114/0x2c0   find_parent_nodes+0x97a/0x17e0   ? ulist_alloc+0x30/0x60   btrfs_find_all_roots_safe+0x97/0x150   iterate_extent_inodes+0x154/0x370   ? btrfs_search_path_in_tree+0x240/0x240   iterate_inodes_from_logical+0x98/0xd0   ? btrfs_search_path_in_tree+0x240/0x240   btrfs_ioctl_logical_to_ino+0xd9/0x180   btrfs_ioctl+0xe2/0x2ec0   ? __mod_memcg_lruvec_state+0x3d/0x280   ? do_sys_openat2+0x6d/0x140   ? kretprobe_dispatcher+0x47/0x70   ? kretprobe_rethook_handler+0x38/0x50   ? rethook_trampoline_handler+0x82/0x140   ? arch_rethook_trampoline_callback+0x3b/0x50   ? kmem_cache_free+0xfb/0x270   ? do_sys_openat2+0xd5/0x140   __x64_sys_ioctl+0x71/0xb0   do_syscall_64+0x2d/0x40Which is this code in tree_mod_log_rewind()	switch (tm->op) {        case BTRFS_MOD_LOG_KEY_REMOVE_WHILE_FREEING:		BUG_ON(tm->slot < n);This occurs because we replay the nodes in order that they happened, andwhen we do a REPLACE we will log a REMOVE_WHILE_FREEING for every slot,starting at 0.   n  here is the number of items in this block, which inthis case was 1, but we had 2 REMOVE_WHILE_FREEING operations.The actual root cause of this was that we were replaying operations fora block that shouldn t have been replayed.  Consider the followingsequence of events1. We have an already modified root, and we do a btrfs_get_tree_mod_seq().2. We begin removing items from this root, triggering KEY_REPLACE for   it s child slots.3. We remove one of the 2 children this root node points to, thus triggering   the root node promotion of the remaining child, and freeing this node.4. We modify a new root, and re-allocate the above node to the root node of   this other root.The tree mod log looks something like this	logical 0	op KEY_REPLACE (slot 1)			seq 2	logical 0	op KEY_REMOVE (slot 1)			seq 3	logical 0	op KEY_REMOVE_WHILE_FREEING (slot 0)	seq 4	logical 4096	op LOG_ROOT_REPLACE (old logical 0)	seq 5	logical 8192	op KEY_REMOVE_WHILE_FREEING (slot 1)	seq 6	logical 8192	op KEY_REMOVE_WHILE_FREEING (slot 0)	seq 7	logical 0	op LOG_ROOT_REPLACE (old logical 8192)	seq 8>From here the bug is triggered by the following steps1.  Call btrfs_get_old_root() on the new_root.2.  We call tree_mod_log_oldest_root(btrfs_root_node(new_root)), which is    currently logical 0.3.  tree_mod_log_oldest_root() calls tree_mod_log_search_oldest(), which    gives us the KEY_REPLACE seq 2, and since that s not a    LOG_ROOT_REPLACE we incorrectly believe that we don t have an old    root, because we expect that the most recent change should be a    LOG_ROOT_REPLACE.4.  Back in tree_mod_log_oldest_root() we don t have a LOG_ROOT_REPLACE,    so we don t set old_root, we simply use our e---truncated---
 漏洞公开时间：2025-05-01 23:16:14
 漏洞创建时间：2025-05-02 01:29:42
 漏洞详情参考链接：
  https://nvd.nist.gov/vuln/detail/CVE-2022-49898
<details>
<summary>更多参考(点击展开)</summary>

| 参考来源 | 参考链接 | 来源链接 |
| ------- | -------- | -------- |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/007058eb8292efc4c88f921752194b83269da085 |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/52b2b65c9eb56fd829dda323786db828627ff7e6 |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/968b71583130b6104c9f33ba60446d598e327a8b |  |
| suse_bugzilla | http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-49898 | https://bugzilla.suse.com/show_bug.cgi?id=1242472 |
| suse_bugzilla | https://www.cve.org/CVERecord?id=CVE-2022-49898 | https://bugzilla.suse.com/show_bug.cgi?id=1242472 |
| suse_bugzilla | https://git.kernel.org/stable/c/007058eb8292efc4c88f921752194b83269da085 | https://bugzilla.suse.com/show_bug.cgi?id=1242472 |
| suse_bugzilla | https://git.kernel.org/stable/c/52b2b65c9eb56fd829dda323786db828627ff7e6 | https://bugzilla.suse.com/show_bug.cgi?id=1242472 |
| suse_bugzilla | https://git.kernel.org/stable/c/968b71583130b6104c9f33ba60446d598e327a8b | https://bugzilla.suse.com/show_bug.cgi?id=1242472 |
| suse_bugzilla | https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2022/CVE-2022-49898.mbox | https://bugzilla.suse.com/show_bug.cgi?id=1242472 |
| suse_bugzilla | https://bugzilla.redhat.com/show_bug.cgi?id=2363425 | https://bugzilla.suse.com/show_bug.cgi?id=1242472 |
| redhat_bugzilla | https://lore.kernel.org/linux-cve-announce/2025050100-CVE-2022-49898-e08b@gregkh/T | https://bugzilla.redhat.com/show_bug.cgi?id=2363425 |
| anolis |  | https://anas.openanolis.cn/cves/detail/CVE-2022-49898 |

</details>

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

无
</details>

二、漏洞分析结构反馈
 影响性分析说明：
  In the Linux kernel, the following vulnerability has been resolved:btrfs: fix tree mod log mishandling of reallocated nodesWe have been seeing the following panic in production  kernel BUG at fs/btrfs/tree-mod-log.c:677!  invalid opcode: 0000 [#1] SMP  RIP: 0010:tree_mod_log_rewind+0x1b4/0x200  RSP: 0000:ffffc9002c02f890 EFLAGS: 00010293  RAX: 0000000000000003 RBX: ffff8882b448c700 RCX: 0000000000000000  RDX: 0000000000008000 RSI: 00000000000000a7 RDI: ffff88877d831c00  RBP: 0000000000000002 R08: 000000000000009f R09: 0000000000000000  R10: 0000000000000000 R11: 0000000000100c40 R12: 0000000000000001  R13: ffff8886c26d6a00 R14: ffff88829f5424f8 R15: ffff88877d831a00  FS:  00007fee1d80c780(0000) GS:ffff8890400c0000(0000) knlGS:0000000000000000  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: 00007fee1963a020 CR3: 0000000434f33002 CR4: 00000000007706e0  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400  PKRU: 55555554  Call Trace:   btrfs_get_old_root+0x12b/0x420   btrfs_search_old_slot+0x64/0x2f0   ? tree_mod_log_oldest_root+0x3d/0xf0   resolve_indirect_ref+0xfd/0x660   ? ulist_alloc+0x31/0x60   ? kmem_cache_alloc_trace+0x114/0x2c0   find_parent_nodes+0x97a/0x17e0   ? ulist_alloc+0x30/0x60   btrfs_find_all_roots_safe+0x97/0x150   iterate_extent_inodes+0x154/0x370   ? btrfs_search_path_in_tree+0x240/0x240   iterate_inodes_from_logical+0x98/0xd0   ? btrfs_search_path_in_tree+0x240/0x240   btrfs_ioctl_logical_to_ino+0xd9/0x180   btrfs_ioctl+0xe2/0x2ec0   ? __mod_memcg_lruvec_state+0x3d/0x280   ? do_sys_openat2+0x6d/0x140   ? kretprobe_dispatcher+0x47/0x70   ? kretprobe_rethook_handler+0x38/0x50   ? rethook_trampoline_handler+0x82/0x140   ? arch_rethook_trampoline_callback+0x3b/0x50   ? kmem_cache_free+0xfb/0x270   ? do_sys_openat2+0xd5/0x140   __x64_sys_ioctl+0x71/0xb0   do_syscall_64+0x2d/0x40Which is this code in tree_mod_log_rewind()switch (tm-&gt;op) {        case BTRFS_MOD_LOG_KEY_REMOVE_WHILE_FREEING:BUG_ON(tm-&gt;slot &lt; n);This occurs because we replay the nodes in order that they happened, andwhen we do a REPLACE we will log a REMOVE_WHILE_FREEING for every slot,starting at 0.  &#39;n&#39; here is the number of items in this block, which inthis case was 1, but we had 2 REMOVE_WHILE_FREEING operations.The actual root cause of this was that we were replaying operations fora block that shouldn&#39;t have been replayed.  Consider the followingsequence of events1. We have an already modified root, and we do a btrfs_get_tree_mod_seq().2. We begin removing items from this root, triggering KEY_REPLACE for   it&#39;s child slots.3. We remove one of the 2 children this root node points to, thus triggering   the root node promotion of the remaining child, and freeing this node.4. We modify a new root, and re-allocate the above node to the root node of   this other root.The tree mod log looks something like thislogical 0op KEY_REPLACE (slot 1)seq 2logical 0op KEY_REMOVE (slot 1)seq 3logical 0op KEY_REMOVE_WHILE_FREEING (slot 0)seq 4logical 4096op LOG_ROOT_REPLACE (old logical 0)seq 5logical 8192op KEY_REMOVE_WHILE_FREEING (slot 1)seq 6logical 8192op KEY_REMOVE_WHILE_FREEING (slot 0)seq 7logical 0op LOG_ROOT_REPLACE (old logical 8192)seq 8<spanclass= q >&gt;From here the bug is triggered by the following steps</span>1.  Call btrfs_get_old_root() on the new_root.2.  We call tree_mod_log_oldest_root(btrfs_root_node(new_root)), which is    currently logical 0.3.  tree_mod_log_oldest_root() calls tree_mod_log_search_oldest(), which    gives us the KEY_REPLACE seq 2, and since that&#39;s not a    LOG_ROOT_REPLACE we incorrectly believe that we don&#39;t have an old    root, because we expect that the most recent change should be a    LOG_ROOT_REPLACE.4.  Back in tree_mod_log_oldest_root() we don&#39;t have a LOG_ROOT_REPLACE,    so we don&#39;t set old_root, we simply use our existing extent buffer.5.  Since we&#39;re using our existing extent buffer (logical 0) we call    tree_mod_log_search(0) in order to get the newest change to start the    rewind from, which ends up being the LOG_ROOT_REPLACE at seq 8.6.  Again since we didn&#39;t find an old_root we simply clone logical 0 at    it&#39;s current state.7.  We call tree_mod_log_rewind() with the cloned extent buffer.8.  Set n = btrfs_header_nritems(logical 0), which would be whatever the    original nritems was when we COWed the original root, say for this    example it&#39;s 2.9.  We start from the newest operation and work our way forward, so we    see LOG_ROOT_REPLACE which we ignore.10. Next we see KEY_REMOVE_WHILE_FREEING for slot 0, which triggers the    BUG_ON(tm-&gt;slot &lt; n), because it expects if we&#39;ve done this we have a    completely empty extent buffer to replay completely.The correct thing would be to find the first LOG_ROOT_REPLACE, and thenget the old_root set to logical 8192.  In fact making that change fixesthis particular problem.However consider the much more complicated case.  We have a child nodein this tree and the above situation.  In the above case we freed oneof the child blocks at the seq 3 operation.  If this block was alsore-allocated and got new tree mod log operations we would have adifferent problem.  btrfs_search_old_slot(orig root) would get down tothe logical 0 root that still pointed at that node.  However inbtrfs_search_old_slot() we call tree_mod_log_rewind(buf) directly.  Thisis not context aware enough to know which operations we should bereplaying.  If the block was re-allocated multiple times we may onlywant to replay a range of operations, and determining what that range isisn&#39;t possible to determine.We could maybe solve this by keeping track of which root the nodebelonged to at every tree mod log operation, and then passing thisaround to make sure we&#39;re only replaying operations that relate to theroot we&#39;re trying to rewind.However there&#39;s a simpler way to solve this problem, simply disallowreallocations if we have currently running tree mod log users.  Wealready do this for leaf&#39;s, so we&#39;re simply expanding this to nodes aswell.  This is a relatively uncommon occurrence, and the problem iscomplicated enough I&#39;m worried that we will still have corner cases inthe reallocation case.  So fix this in the most straightforward waypossible.The Linux kernel CVE team has assigned CVE-2022-49898 to this issue.
 openEuler评分：
  3.9
 Vector：CVSS：3.0/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L
 受影响版本排查(受影响/不受影响)：
  1.openEuler-22.03-LTS-SP3(5.10.0):受影响
2.openEuler-22.03-LTS-SP4(5.10.0):受影响
3.master(6.12.0):不受影响
4.openEuler-20.03-LTS-SP4(4.19.90):不受影响
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):不受影响
8.openEuler-24.03-LTS-SP2(6.6.0):不受影响

修复是否涉及abi变化(是/否)：
  1.master(6.12.0):否
2.openEuler-20.03-LTS-SP4(4.19.90):否
3.openEuler-22.03-LTS-SP3(5.10.0):否
4.openEuler-22.03-LTS-SP4(5.10.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):否
8.openEuler-24.03-LTS-SP2(6.6.0):否

原因说明：
  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.12.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):不受影响-漏洞代码不能被攻击者触发
8.openEuler-24.03-LTS-SP2(6.6.0):不受影响-漏洞代码不能被攻击者触发

src-openEuler/kernel

内容风险标识

评论 (5)

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

内容风险标识

CVE-2022-49898

评论 (5)

搜索帮助

src-openEuler/kernel