Entreprise française de cybersécurité depuis 2004
☎ 03 60 47 09 81 - info@securiteinfo.com
☎ 03 60 47 09 81 - info@securiteinfo.com
In the Linux kernel, the following vulnerability has been resolved:mm/migrate: fix shmem xarray update during migrationA shmem folio can be either in page cache or in swap cache, but not at thesame time. Namely, once it is in swap cache, folio->mapping should beNULL, and the folio is no longer in a shmem mapping.In __folio_migrate_mapping(), to determine the number of xarray entries toupdate, folio_test_swapbacked() is used, but that conflates shmem in pagecache case and shmem in swap cache case. It leads to xarray multi-indexentry corruption, since it turns a sibling entry to a normal entry duringxas_store() (see [1] for a userspace reproduction). Fix it by only usingfolio_test_swapcache() to determine whether xarray is storing swap cacheentries or not to choose the right number of xarray entries to update.[1] https://lore.kernel.org/linux-mm/Z8idPCkaJW1IChjT@casper.infradead.org/Note:In __split_huge_page(), folio_test_anon() && folio_test_swapcache() isused to get swap_cache address space, but that ignores the shmem folio inswap cache case. It could lead to NULL pointer dereferencing when ain-swap-cache shmem folio is split at __xa_store(), since!folio_test_anon() is true and folio->mapping is NULL. But fortunately,its caller split_huge_page_to_list_to_order() bails out early with EBUSYwhen folio->mapping is NULL. So no need to take care of it here.
No PoCs from references.
- https://github.com/w4zu/Debian_security