CVSS
Вероятност да бъде експлоатирана в следващите 30 дни (EPSS)
Атакува се
Време до експлоатация
Описание
Оригинално описание
In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: transfer the pmd dirty bit to the folio on zap zap_huge_pmd_folio() propagates the pmd young bit to the folio for the file case, but not the dirty bit. The pte path does propagate it, in zap_present_folio_ptes() and so does the pmd split path, in __split_huge_pmd_locked(). For most file mappings the omission is harmless, because writing to a shared file mapping goes through page_mkwrite(), which dirties the folio. tmpfs is different: it has no page_mkwrite(), and vma_wants_writenotify() is false for it, so a *read* fault on a MAP_SHARED tmpfs mapping installs a writable pmd via do_read_fault(). do_read_fault() does not call fault_dirty_shared_page(), so subsequent stores through that mapping set only the hardware dirty bit in the pmd and never call folio_mark_dirty(). A shmem folio allocated by a fault is marked uptodate but not dirty (see the clear: block in shmem_get_folio_gfp()), so PG_dirty is never set at all. Unmapping such a folio - munmap(), or exit_mmap() when the process dies - then loses the only record that it was written, because zap_huge_pmd() drops the pmd without transferring the dirty bit. Reclaim afterwards sees a clean shmem folio: the whole swap-out block in shrink_folio_list() is inside "if (folio_test_dirty(folio))", so pageout() is skipped and the folio falls into __remove_mapping(). There, folio_is_file_lru() is false for a swapbacked folio, so no shadow entry is created and __filemap_remove_folio(folio, NULL) simply empties the i_pages slot. The data is freed without ever being written to swap, and the next fault on that index returns a freshly zeroed folio. This is silent data loss for any process that keeps state in a MAP_SHARED tmpfs segment across an unmap - for example a cache handed from one process generation to the next through /dev/shm. It requires the folio to be PMD-mapped, so it only shows up once shmem THP is enabled (which is what w
Засегнати продукти
- Linux Linux: b5072380eb619786990cd9eab3ade05d09ccd89e преди 79d8c89baa10612c1675972a632c65cdbe0936f6; b5072380eb619786990cd9eab3ade05d09ccd89e преди 13f4910d81b62a214cdb28b47237198fa96078a2; b5072380eb619786990cd9eab3ade05d09ccd89e преди 7a4c3f7b47ba34b021a7747081f330bfb76a4271; b5072380eb619786990cd9eab3ade05d09ccd89e преди 6e904f9e8cb0e39f60e1cdbea679f89346a563c2; b5072380eb619786990cd9eab3ade05d09ccd89e преди fd720d3906877b3d2118cd480027e4bc6648f0c5; b5072380eb619786990cd9eab3ade05d09ccd89e преди effe3cc6d4fdd407457eb30f7b0ef094393f0d64; b5072380eb619786990cd9eab3ade05d09ccd89e преди 9435cddf1378d149d826bd7bd1448a44bf96868d; b5072380eb619786990cd9eab3ade05d09ccd89e преди fe6cf984939d8e12cb33a99673c8d026c5135e68
- Linux Linux: 4.8; преди 4.8; 5.10.273 до 5.10.*; 5.15.224 до 5.15.*; 6.1.191 до 6.1.*; 6.6.160 до 6.6.*; 6.12.114 до 6.12.*; 6.18.52 до 6.18.*; 7.2.5 до 7.2.*; от 7.3 нататък
История
- 16 септември 2026 Публикувано
Други уязвимости в Linux Linux
Първоизточници
- https://www.cve.org/CVERecord?id=CVE-2026-89987
- https://nvd.nist.gov/vuln/detail/CVE-2026-89987
- https://git.kernel.org/stable/c/79d8c89baa10612c1675972a632c65cdbe0936f6
- https://git.kernel.org/stable/c/13f4910d81b62a214cdb28b47237198fa96078a2
- https://git.kernel.org/stable/c/7a4c3f7b47ba34b021a7747081f330bfb76a4271
- https://git.kernel.org/stable/c/6e904f9e8cb0e39f60e1cdbea679f89346a563c2
- https://git.kernel.org/stable/c/fd720d3906877b3d2118cd480027e4bc6648f0c5
- https://git.kernel.org/stable/c/effe3cc6d4fdd407457eb30f7b0ef094393f0d64
- https://git.kernel.org/stable/c/9435cddf1378d149d826bd7bd1448a44bf96868d
- https://git.kernel.org/stable/c/fe6cf984939d8e12cb33a99673c8d026c5135e68