CVE-2021-47635: Vulnerability in Linux Linux
In the Linux kernel, the following vulnerability has been resolved: ubifs: Fix to add refcount once page is set private MM defined the rule [1] very clearly that once page was set with PG_private flag, we should increment the refcount in that page, also main flows like pageout(), migrate_page() will assume there is one additional page reference count if page_has_private() returns true. Otherwise, we may get a BUG in page migration: page:0000000080d05b9d refcount:-1 mapcount:0 mapping:000000005f4d82a8 index:0xe2 pfn:0x14c12 aops:ubifs_file_address_operations [ubifs] ino:8f1 dentry name:"f30e" flags: 0x1fffff80002405(locked|uptodate|owner_priv_1|private|node=0| zone=1|lastcpupid=0x1fffff) page dumped because: VM_BUG_ON_PAGE(page_count(page) != 0) ------------[ cut here ]------------ kernel BUG at include/linux/page_ref.h:184! invalid opcode: 0000 [#1] SMP CPU: 3 PID: 38 Comm: kcompactd0 Not tainted 5.15.0-rc5 RIP: 0010:migrate_page_move_mapping+0xac3/0xe70 Call Trace: ubifs_migrate_page+0x22/0xc0 [ubifs] move_to_new_page+0xb4/0x600 migrate_pages+0x1523/0x1cc0 compact_zone+0x8c5/0x14b0 kcompactd+0x2bc/0x560 kthread+0x18c/0x1e0 ret_from_fork+0x1f/0x30 Before the time, we should make clean a concept, what does refcount means in page gotten from grab_cache_page_write_begin(). There are 2 situations: Situation 1: refcount is 3, page is created by __page_cache_alloc. TYPE_A - the write process is using this page TYPE_B - page is assigned to one certain mapping by calling __add_to_page_cache_locked() TYPE_C - page is added into pagevec list corresponding current cpu by calling lru_cache_add() Situation 2: refcount is 2, page is gotten from the mapping's tree TYPE_B - page has been assigned to one certain mapping TYPE_A - the write process is using this page (by calling page_cache_get_speculative()) Filesystem releases one refcount by calling put_page() in xxx_write_end(), the released refcount corresponds to TYPE_A (write task is using it). If there are any processes using a page, page migration process will skip the page by judging whether expected_page_refs() equals to page refcount. The BUG is caused by following process: PA(cpu 0) kcompactd(cpu 1) compact_zone ubifs_write_begin page_a = grab_cache_page_write_begin add_to_page_cache_lru lru_cache_add pagevec_add // put page into cpu 0's pagevec (refcnf = 3, for page creation process) ubifs_write_end SetPagePrivate(page_a) // doesn't increase page count ! unlock_page(page_a) put_page(page_a) // refcnt = 2 [...] PB(cpu 0) filemap_read filemap_get_pages add_to_page_cache_lru lru_cache_add __pagevec_lru_add // traverse all pages in cpu 0's pagevec __pagevec_lru_add_fn SetPageLRU(page_a) isolate_migratepages isolate_migratepages_block get_page_unless_zero(page_a) // refcnt = 3 list_add(page_a, from_list) migrate_pages(from_list) __unmap_and_move move_to_new_page ubifs_migrate_page(page_a) migrate_page_move_mapping expected_page_refs get 3 (migration[1] + mapping[1] + private[1]) release_pages put_page_testzero(page_a) // refcnt = 3 page_ref_freeze // refcnt = 0 page_ref_dec_and_test(0 - 1 = -1) page_ref_unfreeze VM_BUG_ON_PAGE(-1 != 0, page) UBIFS doesn't increase the page refcount after setting private flag, which leads to page migration task believes the page is not used by any other processes, so the page is migrated. This causes concurrent accessing on page refcount between put_page() called by other process(eg. read process calls lru_cache_add) and page_ref_unfreeze() called by mi ---truncated---
AI Analysis
Technical Summary
CVE-2021-47635 is a vulnerability in the Linux kernel's UBIFS (UBI File System) implementation related to improper reference count management when setting the PG_private flag on pages. The issue arises because UBIFS fails to increment the page's reference count after marking it as private, violating the kernel's memory management rules. Normally, when a page is marked private (PG_private flag set), its reference count must be incremented to reflect the additional ownership. The kernel's page migration and compaction routines rely on accurate reference counts to determine if pages are in use and safe to migrate. Due to the missing increment, the page migration process incorrectly assumes the page is unused and proceeds to migrate it concurrently with other processes accessing the page. This leads to a race condition causing a kernel BUG triggered by a negative reference count, resulting in a kernel panic or system crash. The vulnerability is triggered during typical filesystem write and read operations involving page cache management and page migration. The root cause is a logic error in UBIFS's handling of page reference counts during write operations, specifically after setting the private flag without incrementing the refcount. This bug can cause system instability and denial of service due to kernel crashes. There is no indication of remote code execution or privilege escalation directly from this flaw, but the kernel panic can disrupt system availability. The vulnerability affects Linux kernel versions containing the faulty UBIFS code prior to the patch. No known exploits are reported in the wild as of the publication date. The vulnerability requires local access to trigger, as it involves filesystem operations and kernel memory management. No authentication or user interaction beyond normal filesystem usage is needed once local access is obtained. The issue is technical and specific to the UBIFS filesystem implementation in Linux kernels, impacting systems that use UBIFS, typically embedded devices or systems with flash storage using UBI volumes.
Potential Impact
For European organizations, the primary impact of CVE-2021-47635 is on the availability and stability of Linux-based systems utilizing the UBIFS filesystem, commonly found in embedded devices, IoT devices, and specialized industrial equipment. A kernel panic caused by this vulnerability can lead to unexpected system reboots or downtime, disrupting critical operations. Organizations relying on embedded Linux systems in sectors such as manufacturing, telecommunications, automotive, or critical infrastructure could face operational interruptions. Although the vulnerability does not directly compromise confidentiality or integrity, denial of service conditions can affect service continuity and reliability. In environments where embedded Linux devices are used for monitoring, control, or data acquisition, such disruptions could have cascading effects on business processes or safety systems. The lack of known exploits reduces immediate risk, but unpatched systems remain vulnerable to accidental or malicious triggering of the bug. European organizations with supply chains or products incorporating affected Linux kernels should prioritize patching to maintain system stability. The impact is more pronounced in sectors with high reliance on embedded Linux devices running UBIFS, especially where remote or automated recovery is limited.
Mitigation Recommendations
1. Apply the official Linux kernel patches that fix the reference count handling in UBIFS as soon as they become available from trusted sources or Linux distributions. 2. Identify and inventory all systems using UBIFS filesystems, particularly embedded devices and specialized equipment, to assess exposure. 3. For devices where kernel updates are not feasible, consider isolating or restricting access to limit triggering conditions, such as controlling write operations to UBIFS volumes. 4. Implement monitoring to detect kernel panics or unexpected reboots indicative of this issue. 5. For development and testing environments, reproduce the issue to validate patch effectiveness and ensure system stability post-update. 6. Engage with device vendors or suppliers to confirm patch availability and deployment plans for embedded products. 7. Where possible, transition critical systems to filesystems without this vulnerability or to Linux kernel versions confirmed to have the fix. 8. Establish robust backup and recovery procedures to minimize downtime impact in case of crashes. 9. Educate system administrators and embedded device operators about the symptoms and risks associated with this vulnerability to enable prompt response.
Affected Countries
Germany, France, United Kingdom, Netherlands, Sweden, Finland, Italy
CVE-2021-47635: Vulnerability in Linux Linux
Description
In the Linux kernel, the following vulnerability has been resolved: ubifs: Fix to add refcount once page is set private MM defined the rule [1] very clearly that once page was set with PG_private flag, we should increment the refcount in that page, also main flows like pageout(), migrate_page() will assume there is one additional page reference count if page_has_private() returns true. Otherwise, we may get a BUG in page migration: page:0000000080d05b9d refcount:-1 mapcount:0 mapping:000000005f4d82a8 index:0xe2 pfn:0x14c12 aops:ubifs_file_address_operations [ubifs] ino:8f1 dentry name:"f30e" flags: 0x1fffff80002405(locked|uptodate|owner_priv_1|private|node=0| zone=1|lastcpupid=0x1fffff) page dumped because: VM_BUG_ON_PAGE(page_count(page) != 0) ------------[ cut here ]------------ kernel BUG at include/linux/page_ref.h:184! invalid opcode: 0000 [#1] SMP CPU: 3 PID: 38 Comm: kcompactd0 Not tainted 5.15.0-rc5 RIP: 0010:migrate_page_move_mapping+0xac3/0xe70 Call Trace: ubifs_migrate_page+0x22/0xc0 [ubifs] move_to_new_page+0xb4/0x600 migrate_pages+0x1523/0x1cc0 compact_zone+0x8c5/0x14b0 kcompactd+0x2bc/0x560 kthread+0x18c/0x1e0 ret_from_fork+0x1f/0x30 Before the time, we should make clean a concept, what does refcount means in page gotten from grab_cache_page_write_begin(). There are 2 situations: Situation 1: refcount is 3, page is created by __page_cache_alloc. TYPE_A - the write process is using this page TYPE_B - page is assigned to one certain mapping by calling __add_to_page_cache_locked() TYPE_C - page is added into pagevec list corresponding current cpu by calling lru_cache_add() Situation 2: refcount is 2, page is gotten from the mapping's tree TYPE_B - page has been assigned to one certain mapping TYPE_A - the write process is using this page (by calling page_cache_get_speculative()) Filesystem releases one refcount by calling put_page() in xxx_write_end(), the released refcount corresponds to TYPE_A (write task is using it). If there are any processes using a page, page migration process will skip the page by judging whether expected_page_refs() equals to page refcount. The BUG is caused by following process: PA(cpu 0) kcompactd(cpu 1) compact_zone ubifs_write_begin page_a = grab_cache_page_write_begin add_to_page_cache_lru lru_cache_add pagevec_add // put page into cpu 0's pagevec (refcnf = 3, for page creation process) ubifs_write_end SetPagePrivate(page_a) // doesn't increase page count ! unlock_page(page_a) put_page(page_a) // refcnt = 2 [...] PB(cpu 0) filemap_read filemap_get_pages add_to_page_cache_lru lru_cache_add __pagevec_lru_add // traverse all pages in cpu 0's pagevec __pagevec_lru_add_fn SetPageLRU(page_a) isolate_migratepages isolate_migratepages_block get_page_unless_zero(page_a) // refcnt = 3 list_add(page_a, from_list) migrate_pages(from_list) __unmap_and_move move_to_new_page ubifs_migrate_page(page_a) migrate_page_move_mapping expected_page_refs get 3 (migration[1] + mapping[1] + private[1]) release_pages put_page_testzero(page_a) // refcnt = 3 page_ref_freeze // refcnt = 0 page_ref_dec_and_test(0 - 1 = -1) page_ref_unfreeze VM_BUG_ON_PAGE(-1 != 0, page) UBIFS doesn't increase the page refcount after setting private flag, which leads to page migration task believes the page is not used by any other processes, so the page is migrated. This causes concurrent accessing on page refcount between put_page() called by other process(eg. read process calls lru_cache_add) and page_ref_unfreeze() called by mi ---truncated---
AI-Powered Analysis
Technical Analysis
CVE-2021-47635 is a vulnerability in the Linux kernel's UBIFS (UBI File System) implementation related to improper reference count management when setting the PG_private flag on pages. The issue arises because UBIFS fails to increment the page's reference count after marking it as private, violating the kernel's memory management rules. Normally, when a page is marked private (PG_private flag set), its reference count must be incremented to reflect the additional ownership. The kernel's page migration and compaction routines rely on accurate reference counts to determine if pages are in use and safe to migrate. Due to the missing increment, the page migration process incorrectly assumes the page is unused and proceeds to migrate it concurrently with other processes accessing the page. This leads to a race condition causing a kernel BUG triggered by a negative reference count, resulting in a kernel panic or system crash. The vulnerability is triggered during typical filesystem write and read operations involving page cache management and page migration. The root cause is a logic error in UBIFS's handling of page reference counts during write operations, specifically after setting the private flag without incrementing the refcount. This bug can cause system instability and denial of service due to kernel crashes. There is no indication of remote code execution or privilege escalation directly from this flaw, but the kernel panic can disrupt system availability. The vulnerability affects Linux kernel versions containing the faulty UBIFS code prior to the patch. No known exploits are reported in the wild as of the publication date. The vulnerability requires local access to trigger, as it involves filesystem operations and kernel memory management. No authentication or user interaction beyond normal filesystem usage is needed once local access is obtained. The issue is technical and specific to the UBIFS filesystem implementation in Linux kernels, impacting systems that use UBIFS, typically embedded devices or systems with flash storage using UBI volumes.
Potential Impact
For European organizations, the primary impact of CVE-2021-47635 is on the availability and stability of Linux-based systems utilizing the UBIFS filesystem, commonly found in embedded devices, IoT devices, and specialized industrial equipment. A kernel panic caused by this vulnerability can lead to unexpected system reboots or downtime, disrupting critical operations. Organizations relying on embedded Linux systems in sectors such as manufacturing, telecommunications, automotive, or critical infrastructure could face operational interruptions. Although the vulnerability does not directly compromise confidentiality or integrity, denial of service conditions can affect service continuity and reliability. In environments where embedded Linux devices are used for monitoring, control, or data acquisition, such disruptions could have cascading effects on business processes or safety systems. The lack of known exploits reduces immediate risk, but unpatched systems remain vulnerable to accidental or malicious triggering of the bug. European organizations with supply chains or products incorporating affected Linux kernels should prioritize patching to maintain system stability. The impact is more pronounced in sectors with high reliance on embedded Linux devices running UBIFS, especially where remote or automated recovery is limited.
Mitigation Recommendations
1. Apply the official Linux kernel patches that fix the reference count handling in UBIFS as soon as they become available from trusted sources or Linux distributions. 2. Identify and inventory all systems using UBIFS filesystems, particularly embedded devices and specialized equipment, to assess exposure. 3. For devices where kernel updates are not feasible, consider isolating or restricting access to limit triggering conditions, such as controlling write operations to UBIFS volumes. 4. Implement monitoring to detect kernel panics or unexpected reboots indicative of this issue. 5. For development and testing environments, reproduce the issue to validate patch effectiveness and ensure system stability post-update. 6. Engage with device vendors or suppliers to confirm patch availability and deployment plans for embedded products. 7. Where possible, transition critical systems to filesystems without this vulnerability or to Linux kernel versions confirmed to have the fix. 8. Establish robust backup and recovery procedures to minimize downtime impact in case of crashes. 9. Educate system administrators and embedded device operators about the symptoms and risks associated with this vulnerability to enable prompt response.
Affected Countries
For access to advanced analysis and higher rate limits, contact root@offseq.com
Technical Details
- Data Version
- 5.1
- Assigner Short Name
- Linux
- Date Reserved
- 2025-02-26T01:48:21.518Z
- Cisa Enriched
- false
- Cvss Version
- null
- State
- PUBLISHED
Threat ID: 682d9834c4522896dcbe961d
Added to database: 5/21/2025, 9:09:08 AM
Last enriched: 6/30/2025, 3:40:53 PM
Last updated: 7/26/2025, 3:52:53 PM
Views: 10
Related Threats
CVE-2025-8885: CWE-770 Allocation of Resources Without Limits or Throttling in Legion of the Bouncy Castle Inc. Bouncy Castle for Java
MediumCVE-2025-26398: CWE-798 Use of Hard-coded Credentials in SolarWinds Database Performance Analyzer
MediumCVE-2025-41686: CWE-306 Missing Authentication for Critical Function in Phoenix Contact DaUM
HighCVE-2025-8874: CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') in litonice13 Master Addons – Elementor Addons with White Label, Free Widgets, Hover Effects, Conditions, & Animations
MediumCVE-2025-8767: CWE-1236 Improper Neutralization of Formula Elements in a CSV File in anwppro AnWP Football Leagues
MediumActions
Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.
External Links
Need enhanced features?
Contact root@offseq.com for Pro access with improved analysis and higher rate limits.