CVE-2021-47635

{"id": "CVE-2021-47635", "cveTags": [], "metrics": {"cvssMetricV31": [{"type": "Primary", "source": "nvd@nist.gov", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 5.5, "attackVector": "LOCAL", "baseSeverity": "MEDIUM", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "integrityImpact": "NONE", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "LOW", "confidentialityImpact": "NONE"}, "impactScore": 3.6, "exploitabilityScore": 1.8}]}, "published": "2025-02-26T06:37:05.280", "references": [{"url": "https://git.kernel.org/stable/c/3b67db8a6ca83e6ff90b756d3da0c966f61cd37b", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/4f75bab98565afd4f905059c56ec4caba88a7eec", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/5aaa2c0f0052b02c4a982993d4c5bb68fb7cbe22", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/c34ae24a2590fee96a3a7735ba2fa6cc52306221", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/fbeb2139eed65e929ce806c6468e6601ade01b1b", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Analyzed", "weaknesses": [{"type": "Primary", "source": "nvd@nist.gov", "description": [{"lang": "en", "value": "NVD-CWE-Other"}]}], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nubifs: Fix to add refcount once page is set private\n\nMM defined the rule [1] very clearly that once page was set with PG_private\nflag, we should increment the refcount in that page, also main flows like\npageout(), migrate_page() will assume there is one additional page\nreference count if page_has_private() returns true. Otherwise, we may\nget a BUG in page migration:\n\n page:0000000080d05b9d refcount:-1 mapcount:0 mapping:000000005f4d82a8\n index:0xe2 pfn:0x14c12\n aops:ubifs_file_address_operations [ubifs] ino:8f1 dentry name:\"f30e\"\n flags: 0x1fffff80002405(locked|uptodate|owner_priv_1|private|node=0|\n zone=1|lastcpupid=0x1fffff)\n page dumped because: VM_BUG_ON_PAGE(page_count(page) != 0)\n ------------[ cut here ]------------\n kernel BUG at include/linux/page_ref.h:184!\n invalid opcode: 0000 [#1] SMP\n CPU: 3 PID: 38 Comm: kcompactd0 Not tainted 5.15.0-rc5\n RIP: 0010:migrate_page_move_mapping+0xac3/0xe70\n Call Trace:\n ubifs_migrate_page+0x22/0xc0 [ubifs]\n move_to_new_page+0xb4/0x600\n migrate_pages+0x1523/0x1cc0\n compact_zone+0x8c5/0x14b0\n kcompactd+0x2bc/0x560\n kthread+0x18c/0x1e0\n ret_from_fork+0x1f/0x30\n\nBefore the time, we should make clean a concept, what does refcount means\nin page gotten from grab_cache_page_write_begin(). There are 2 situations:\nSituation 1: refcount is 3, page is created by __page_cache_alloc.\n TYPE_A - the write process is using this page\n TYPE_B - page is assigned to one certain mapping by calling\n\t __add_to_page_cache_locked()\n TYPE_C - page is added into pagevec list corresponding current cpu by\n\t calling lru_cache_add()\nSituation 2: refcount is 2, page is gotten from the mapping's tree\n TYPE_B - page has been assigned to one certain mapping\n TYPE_A - the write process is using this page (by calling\n\t page_cache_get_speculative())\nFilesystem releases one refcount by calling put_page() in xxx_write_end(),\nthe released refcount corresponds to TYPE_A (write task is using it). If\nthere are any processes using a page, page migration process will skip the\npage by judging whether expected_page_refs() equals to page refcount.\n\nThe BUG is caused by following process:\n PA(cpu 0) kcompactd(cpu 1)\n\t\t\t\tcompact_zone\nubifs_write_begin\n page_a = grab_cache_page_write_begin\n add_to_page_cache_lru\n lru_cache_add\n pagevec_add // put page into cpu 0's pagevec\n (refcnf = 3, for page creation process)\nubifs_write_end\n SetPagePrivate(page_a) // doesn't increase page count !\n unlock_page(page_a)\n put_page(page_a) // refcnt = 2\n\t\t\t\t[...]\n\n PB(cpu 0)\nfilemap_read\n filemap_get_pages\n add_to_page_cache_lru\n lru_cache_add\n __pagevec_lru_add // traverse all pages in cpu 0's pagevec\n\t __pagevec_lru_add_fn\n\t SetPageLRU(page_a)\n\t\t\t\tisolate_migratepages\n isolate_migratepages_block\n\t\t\t\t get_page_unless_zero(page_a)\n\t\t\t\t // refcnt = 3\n list_add(page_a, from_list)\n\t\t\t\tmigrate_pages(from_list)\n\t\t\t\t __unmap_and_move\n\t\t\t\t move_to_new_page\n\t\t\t\t ubifs_migrate_page(page_a)\n\t\t\t\t migrate_page_move_mapping\n\t\t\t\t\t expected_page_refs get 3\n (migration[1] + mapping[1] + private[1])\n\t release_pages\n\t put_page_testzero(page_a) // refcnt = 3\n page_ref_freeze // refcnt = 0\n\t page_ref_dec_and_test(0 - 1 = -1)\n page_ref_unfreeze\n VM_BUG_ON_PAGE(-1 != 0, page)\n\nUBIFS doesn't increase the page refcount after setting private flag, which\nleads to page migration task believes the page is not used by any other\nprocesses, so the page is migrated. This causes concurrent accessing on\npage refcount between put_page() called by other process(eg. read process\ncalls lru_cache_add) and page_ref_unfreeze() called by mi\n---truncated---"}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ubifs: Correcci\u00f3n para agregar refcount una vez que la p\u00e1gina se establece como privada MM defini\u00f3 la regla [1] muy claramente que una vez que la p\u00e1gina se establece con el indicador PG_private, debemos incrementar el refcount en esa p\u00e1gina, tambi\u00e9n los flujos principales como pageout(), migrants_page() asumir\u00e1n que hay un recuento de referencia de p\u00e1gina adicional si page_has_private() devuelve verdadero. De lo contrario, podemos obtener un ERROR en la migraci\u00f3n de la p\u00e1gina: 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) p\u00e1gina volcada porque: VM_BUG_ON_PAGE(page_count(page) != 0) ------------[ cortar aqu\u00ed ]------------ \u00a1ERROR del kernel en include/linux/page_ref.h:184! c\u00f3digo de operaci\u00f3n no v\u00e1lido: 0000 [#1] CPU SMP: 3 PID: 38 Comm: kcompactd0 No contaminado 5.15.0-rc5 RIP: 0010:migrate_page_move_mapping+0xac3/0xe70 Rastreo de llamadas: ubifs_migrate_page+0x22/0xc0 [ubifs] move_to_new_page+0xb4/0x600 migrants_pages+0x1523/0x1cc0 compact_zone+0x8c5/0x14b0 kcompactd+0x2bc/0x560 kthread+0x18c/0x1e0 ret_from_fork+0x1f/0x30 Antes de tiempo, deber\u00edamos aclarar un concepto, qu\u00e9 significa refcount en la p\u00e1gina obtenida de grab_cache_page_write_begin(). Hay 2 situaciones: Situaci\u00f3n 1: refcount es 3, la p\u00e1gina es creada por __page_cache_alloc. TYPE_A - el proceso de escritura est\u00e1 usando esta p\u00e1gina TYPE_B - la p\u00e1gina es asignada a un cierto mapeo llamando a __add_to_page_cache_locked() TYPE_C - la p\u00e1gina es agregada a la lista pagevec correspondiente a la CPU actual llamando a lru_cache_add() Situaci\u00f3n 2: refcount es 2, la p\u00e1gina es obtenida del \u00e1rbol del mapeo TYPE_B - la p\u00e1gina ha sido asignada a un cierto mapeo TYPE_A - el proceso de escritura est\u00e1 usando esta p\u00e1gina (llamando a page_cache_get_speculative()) El sistema de archivos libera un refcount llamando a put_page() en xxx_write_end(), el refcount liberado corresponde a TYPE_A (la tarea de escritura lo est\u00e1 usando). Si hay alg\u00fan proceso usando una p\u00e1gina, el proceso de migraci\u00f3n de p\u00e1gina omitir\u00e1 la p\u00e1gina al juzgar si expected_page_refs() es igual a page refcount. El ERROR es causado por el siguiente proceso: 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 // coloca la p\u00e1gina en el pagevec de la CPU 0 (refcnf = 3, para el proceso de creaci\u00f3n de la p\u00e1gina) ubifs_write_end SetPagePrivate(page_a) // \u00a1no aumenta el n\u00famero de p\u00e1ginas! 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 no aumenta el recuento de referencias de la p\u00e1gina despu\u00e9s de configurar el indicador privado, lo que hace que la tarea de migraci\u00f3n de la p\u00e1gina crea que ning\u00fan otro proceso utiliza la p\u00e1gina, por lo que se migra la p\u00e1gina. Esto provoca un acceso simult\u00e1neo al recuento de referencias de la p\u00e1gina entre put_page() llamado por otro proceso (por ejemplo, el proceso de lectura llama a lru_cache_add) y page_ref_unfreeze() llamado por mi ---truncated---"}], "lastModified": "2025-09-23T18:46:00.077", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "0E0C611D-BB2E-4D53-8B88-9AA9DA93C3E8", "versionEndExcluding": "5.10.110", "versionStartIncluding": "2.6.27"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "27C42AE8-B387-43E2-938A-E1C8B40BE6D5", "versionEndExcluding": "5.15.33", "versionStartIncluding": "5.11"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "20C43679-0439-405A-B97F-685BEE50613B", "versionEndExcluding": "5.16.19", "versionStartIncluding": "5.16"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "210C679C-CF84-44A3-8939-E629C87E54BF", "versionEndExcluding": "5.17.2", "versionStartIncluding": "5.17"}], "operator": "OR"}]}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}