CVE-2022-48802 in Linux
Summary
by MITRE • 07/16/2024
In the Linux kernel, the following vulnerability has been resolved:
fs/proc: task_mmu.c: don't read mapcount for migration entry
The syzbot reported the below BUG:
kernel BUG at include/linux/page-flags.h:785! invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 4392 Comm: syz-executor560 Not tainted 5.16.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:PageDoubleMap include/linux/page-flags.h:785 [inline]
RIP: 0010:__page_mapcount+0x2d2/0x350 mm/util.c:744 Call Trace: page_mapcount include/linux/mm.h:837 [inline]
smaps_account+0x470/0xb10 fs/proc/task_mmu.c:466 smaps_pte_entry fs/proc/task_mmu.c:538 [inline]
smaps_pte_range+0x611/0x1250 fs/proc/task_mmu.c:601 walk_pmd_range mm/pagewalk.c:128 [inline]
walk_pud_range mm/pagewalk.c:205 [inline]
walk_p4d_range mm/pagewalk.c:240 [inline]
walk_pgd_range mm/pagewalk.c:277 [inline]
__walk_page_range+0xe23/0x1ea0 mm/pagewalk.c:379 walk_page_vma+0x277/0x350 mm/pagewalk.c:530 smap_gather_stats.part.0+0x148/0x260 fs/proc/task_mmu.c:768 smap_gather_stats fs/proc/task_mmu.c:741 [inline]
show_smap+0xc6/0x440 fs/proc/task_mmu.c:822 seq_read_iter+0xbb0/0x1240 fs/seq_file.c:272 seq_read+0x3e0/0x5b0 fs/seq_file.c:162 vfs_read+0x1b5/0x600 fs/read_write.c:479 ksys_read+0x12d/0x250 fs/read_write.c:619 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae
The reproducer was trying to read /proc/$PID/smaps when calling MADV_FREE at the mean time. MADV_FREE may split THPs if it is called for partial THP. It may trigger the below race:
CPU A CPU B ----- ----- smaps walk: MADV_FREE: page_mapcount() PageCompound() split_huge_page() page = compound_head(page) PageDoubleMap(page)
When calling PageDoubleMap() this page is not a tail page of THP anymore so the BUG is triggered.
This could be fixed by elevated refcount of the page before calling mapcount, but that would prevent it from counting migration entries, and it seems overkilling because the race just could happen when PMD is split so all PTE entries of tail pages are actually migration entries, and smaps_account() does treat migration entries as mapcount == 1 as Kirill pointed out.
Add a new parameter for smaps_account() to tell this entry is migration entry then skip calling page_mapcount(). Don't skip getting mapcount for device private entries since they do track references with mapcount.
Pagemap also has the similar issue although it was not reported. Fixed it as well.
[[email protected]: v4]
Link: https://lkml.kernel.org/r/[email protected] [[email protected]: avoid unused variable warning in pagemap_pmd_range()]
Link: https://lkml.kernel.org/r/[email protected]
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/03/2025
The vulnerability described in CVE-2022-48802 resides within the Linux kernel's memory management subsystem, specifically in the /proc/$PID/smaps file handling mechanism. This issue manifests as a kernel BUG triggered when attempting to read process memory maps while a memory management operation called MADV_FREE is concurrently executing. The problem occurs during the traversal of page table entries for memory accounting purposes, where the kernel attempts to access a page's mapcount value for a page that has been modified by the memory splitting operation. This race condition leads to an invalid memory access and subsequent kernel panic, as evidenced by the kernel crash log showing an invalid opcode execution at include/linux/page-flags.h:785.
The technical root cause involves a race condition between memory management operations and memory accounting functions. When a process attempts to read /proc/$PID/smaps and simultaneously calls MADV_FREE, the memory subsystem may split transparent huge pages (THPs) during the MADV_FREE operation. During this split, tail pages of the THP are converted into migration entries, but the memory accounting code in smaps_account() continues to attempt to read the mapcount of these pages. The PageDoubleMap() function call fails because the page is no longer a tail page of a THP, causing the kernel to execute an invalid instruction and trigger a BUG. This vulnerability is classified under CWE-362 as a race condition that leads to improper access to shared resources.
The operational impact of this vulnerability is significant for systems running Linux kernels with memory management features enabled. The exploitation of this vulnerability can result in kernel panics and system crashes, leading to denial of service conditions that affect all running processes on the affected system. Attackers could potentially leverage this vulnerability to cause system instability or perform DoS attacks against systems that frequently use memory management operations such as MADV_FREE or THP splitting. The vulnerability affects systems that rely heavily on memory accounting and monitoring through /proc filesystem interfaces, particularly those with high memory management activity. This issue also impacts pagemap functionality which shares similar underlying code paths, making it a broader memory management concern.
Mitigation strategies for CVE-2022-48802 include applying the kernel patches provided by the Linux kernel security team, which introduce a new parameter to the smaps_account() function to properly handle migration entries without attempting to read mapcount values from pages that have been converted to migration entries. The fix specifically addresses the issue by skipping mapcount calls for migration entries while preserving the ability to properly account for device private entries that do track references through mapcount. System administrators should ensure their kernel versions are updated to include this fix, particularly on systems that perform frequent memory management operations or rely heavily on memory accounting features. The patch also addresses similar issues in pagemap functionality, providing comprehensive coverage for memory management subsystem vulnerabilities. Organizations should monitor their kernel versions and apply security updates promptly to prevent exploitation of this and related memory management vulnerabilities.