hyeonjun17/cve-2022-2590-analysisEingehende Analyse von CVE-2022-2590, einer Race Condition im Linux-Kernel im gemeinsamen Speicher (shmem), die beliebiges Schreiben auf schreibgeschützte Seiten über userfaultfd und FOLL_FORCE/COW-Bypass ermöglicht.
Linux-Kernel-Version: Linux/x86 6.0.0-rc1 (Commit 37887783b3fef877bf34b8992c9199864da4afcb)
Diese Schwachstelle erlaubt es dem Angreifer, beliebige Inhalte in eine schreibgeschützte Shared-Memory-Seite zu schreiben, indem die Funktion can_follow_write_pte erfüllt wird, die FOLL_FORCE, FOLL_COW und pte_dirty überprüft, unter Verwendung von UFFDIO_CONTINUE.
/*
* FOLL_FORCE can write to even unwritable pte's, but only
* after we've gone through a COW cycle and they are dirty.
*/
static inline bool can_follow_write_pte(pte_t pte, unsigned int flags)
{
return pte_write(pte) ||
((flags & FOLL_FORCE) && (flags & FOLL_COW) && pte_dirty(pte));
}
Die obige Funktion bestimmt, ob eine pte beschreibbar ist.
Die pte gilt als beschreibbar, wenn eine der folgenden Bedingungen erfüllt ist:
flags enthält die Flags FOLL_FORCE und FOLL_COW, und die Flags der pte enthalten das Dirty-Flag.Um Bedingung 2 zu erfüllen, müssen die folgenden drei Flags gesetzt sein:
FOLL_FORCE
static ssize_t mem_rw(struct file *file, char __user *buf,
size_t count, loff_t *ppos, int write)
{
...
flags = FOLL_FORCE | (write ? FOLL_WRITE : 0);
while (count > 0) {
size_t this_len = min_t(size_t, count, PAGE_SIZE);
if (write && copy_from_user(page, buf, this_len)) {
copied = -EFAULT;
break;
}
this_len = access_remote_vm(mm, addr, page, this_len, flags); // __get_user_pages with FOLL_FORCE on
if (!this_len) {
if (!copied)
copied = -EIO;
break;
}
...
}
Die obige Funktion führt Lese-/Schreiboperationen auf /proc/<pid>/mem durch.
Mit dieser Funktion kann die __get_user_pages-Funktion mit gesetztem FOLL_FORCE-Flag erreicht werden.
Obwohl FOLL_FORCE für die Verwendung in ptrace gedacht ist, wurde seine Notwendigkeit im folgenden Commit nachgewiesen: https://github.com/torvalds/linux/commit/f511c0b17b081562dca8ac5061dfa86db4c66cc2
FOLL_COW
/*
* mmap_lock must be held on entry. If @locked != NULL and *@flags
* does not include FOLL_NOWAIT, the mmap_lock may be released. If it
* is, *@locked will be set to 0 and -EBUSY returned.
*/
static int faultin_page(struct vm_area_struct *vma,
unsigned long address, unsigned int *flags, bool unshare,
int *locked)
{
...
/*
* The VM_FAULT_WRITE bit tells us that do_wp_page has broken COW when
* necessary, even if maybe_mkwrite decided not to set pte_write. We
* can thus safely do subsequent page lookups as if they were reads.
* But only do so when looping for pte_write is futile: in some cases
* userspace may also be wanting to write to the gotten user page,
* which a read fault here might prevent (a readonly page might get
* reCOWed by userspace write).
*/
if ((ret & VM_FAULT_WRITE) && !(vma->vm_flags & VM_WRITE))
*flags |= FOLL_COW;
return 0;
}
Die ODER-Verknüpfung mit FOLL_COW in der faultin_page-Funktion kann verwendet werden, die Teil des Patches für Dirty COW ist.
static long __get_user_pages(struct mm_struct *mm,
unsigned long start, unsigned long nr_pages,
unsigned int gup_flags, struct page **pages,
struct vm_area_struct **vmas, int *locked)
{
...
retry:
/*
* If we have a pending SIGKILL, don't keep faulting pages and
* potentially allocating memory.
*/
if (fatal_signal_pending(current)) {
ret = -EINTR;
goto out;
}
cond_resched();
page = follow_page_mask(vma, start, foll_flags, &ctx); // can_follow_write_pte
if (!page || PTR_ERR(page) == -EMLINK) {
ret = faultin_page(vma, start, &foll_flags,
PTR_ERR(page) == -EMLINK, locked); // flags |= FOLL_COW
switch (ret) {
case 0:
goto retry; // try follow page again
case -EBUSY:
case -EAGAIN:
ret = 0;
fallthrough;
case -EFAULT:
case -ENOMEM:
case -EHWPOISON:
goto out;
}
BUG();
} else if (PTR_ERR(page) == -EEXIST) {
...
}
Um die can_follow_write_pte-Funktion mit gesetztem FOLL_COW-Flag zu erreichen, muss die faultin_page-Funktion innerhalb der __get_user_pages-Funktion aufgerufen werden, dann zum Label retry gesprungen und die faultin_page-Funktion erneut aufgerufen werden.
pte_dirty
Diese Bedingung kann aufgrund des folgenden Commits erfüllt werden: https://github.com/torvalds/linux/commit/9ae0f87d009ca6c4aab2882641ddfc319727e3db
/*
* Install PTEs, to map dst_addr (within dst_vma) to page.
*
* This function handles both MCOPY_ATOMIC_NORMAL and _CONTINUE for both shmem
* and anon, and for both shared and private VMAs.
*/
int mfill_atomic_install_pte(struct mm_struct *dst_mm, pmd_t *dst_pmd,
struct vm_area_struct *dst_vma,
unsigned long dst_addr, struct page *page,
bool newly_allocated, bool wp_copy)
{
...
_dst_pte = mk_pte(page, dst_vma->vm_page_prot);
_dst_pte = pte_mkdirty(_dst_pte); // set pte dirty unconditionally
if (page_in_cache && !vm_shared)
writable = false;
...
}
Aufgrund des obigen Patches ist es möglich, eine pte für die schreibgeschützte Shared-Memory-Seite bedingungslos in einem Dirty-Zustand zu installieren.
Wenn diese drei Flags erfüllt sind, gibt die can_follow_write_pte-Funktion true zurück.
static struct page *follow_page_pte(struct vm_area_struct *vma,
unsigned long address, pmd_t *pmd, unsigned int flags,
struct dev_pagemap **pgmap)
{
...
// true && !true == false
if ((flags & FOLL_WRITE) && !can_follow_write_pte(pte, flags)) {
pte_unmap_unlock(ptep, ptl);
return NULL;
}
page = vm_normal_page(vma, address, pte); // get read-only shared memory page
...
out:
pte_unmap_unlock(ptep, ptl);
return page;
no_page:
pte_unmap_unlock(ptep, ptl);
if (!pte_none(pte))
return NULL;
return no_page_table(vma, flags);
}
Die Funktion follow_page_pte gibt die schreibgeschützte Shared-Memory-Seite zurück.
Im Folgenden wird das Race-Szenario beschrieben, das durch den später vorgestellten PoC nachgewiesen wurde.
| madvise und lesen | UFFDIO_CONTINUE ioctl | pwrite |
|---|---|---|
| madvise // Seite entfernen | ||
| shmem_fault // Lesefehler | ||
| handle_userfault | ||
| userfaultfd_continue | ||
| mcontinue_atomic_pte | ||
| ret = shmem_getpage(inode, pgoff, &page, SGP_NOALLOC); // Seite holen | ||
| mfill_atomic_install_pte | ||
| _dst_pte = pte_mkdirty(_dst_pte); // pte dirty setzen | ||
| set_pte_at(dst_mm, dst_addr, dst_pte, _dst_pte); // pte installieren | mem_rw | |
| access_remote_vm // mit FOLL_FORCE | ||
| __get_user_pages | ||
| can_follow_write_pte // kein FOLL_COW, gibt 0 zurück | ||
| faultin_page | ||
| flags | ||
| retry: | ||
| follow_page_pte | ||
| madvise // Seite entfernen | ||
| shmem_fault // Lesefehler | ||
| handle_userfault | ||
| userfaultfd_continue | ||
| mcontinue_atomic_pte | ||
| ret = shmem_getpage(inode, pgoff, &page, SGP_NOALLOC); // Seite holen | ||
| mfill_atomic_install_pte | ||
| _dst_pte = pte_mkdirty(_dst_pte); // pte dirty setzen | ||
| set_pte_at(dst_mm, dst_addr, dst_pte, _dst_pte); // pte installieren | ||
| can_follow_write_pte // gibt 1 zurück | ||
| copy_to_user(buf, page, this_len) // Inhalt in schreibgeschützte Seite schreiben |
Die madvise- und Lese-Routinen werden zweimal ausgeführt; die erste Ausführung löst ein retry von __get_user_pages aus, und die zweite Ausführung führt follow_page_pte dazu, die Seite zurückzugeben, auf die durch die pte verwiesen wird, die von mfill_atomic_install_pte als dirty markiert wurde.
Sie können David Hildenbrands Reproducer unter dem obigen Link überprüfen.
Da der Reproducer es jedoch schwierig macht, das genaue Race-Szenario zu erkennen, habe ich den Reproducer modifiziert, um eine linearere Ausführung zu bevorzugen, und entsprechend auch den Linux-Kernel-Quellcode angepasst.
.config:
...
CONFIG_USERFAULTFD=y
CONFIG_HAVE_ARCH_USERFAULTFD_WP=y
CONFIG_HAVE_ARCH_USERFAULTFD_MINOR=y
...
PoC: (poc.c)
Patch: (poc_deayzl.patch)
Für Tests müssen die folgenden vorbereitenden Schritte ausgeführt werden. (Die Anweisungen in Davids Reproducer geben den Dateipfad als /tmp/foo an. tmpfs ist jedoch in der aktuellen Version kein Shared Memory, daher schlägt die userfaultfd-Registrierung fehl.)
sudo -s
echo "asdf" > /dev/shm/foo
chmod 0404 /dev/shm/foo
exit
Nach dem Ausführen des PoC sehen Sie den folgenden Bildschirm.
lore.kernel Patch v1: https://lore.kernel.org/linux-mm/[email protected]/#r
lore.kernel Patch v2: https://lore.kernel.org/all/[email protected]/T/#u