From: Tugrul Kukul <tugrul.kukul@est.tech>

This series fixes CVE-2024-27022 on 6.6 stable by first backporting the
necessary vfio refactoring, then applying the fork fix.

== Background ==

CVE-2024-27022 is a race condition in dup_mmap() during fork() where a
file-backed VMA becomes visible through the i_mmap tree before it is
fully initialized. A concurrent hugetlbfs operation (fallocate/punch_hole)
can access the VMA with a NULL or inconsistent vma_lock, causing a kernel
deadlock or WARNING.

The mainline fix (35e351780fa9, v6.9-rc5) defers linking the file VMA
into the i_mmap tree until the VMA is fully initialized.

== Why this hasn't been fixed in 6.6 until now ==

This CVE has had a troubled backport history on 6.6 stable:

1. cec11fa2eb51 - Incomplete backport to 6.6, only moved
   hugetlb_dup_vma_private() and vm_ops->open() but left
   vma_iter_bulk_store() and mm->map_count++ in place.
   Caused xfstests failures.

2. dd782da47076 - Sam James reverted the incomplete backport. [1]

3. Leah Rumancik attempted a correct backport but discovered it
   introduced a vfio-pci ordering issue: vm_ops->open() being called
   before copy_page_range() breaks vfio-pci's zap-then-fault mechanism.
   Leah withdrew the patch. [2]

4. Axel Rasmussen backported Alex Williamson's 3 vfio refactor
   commits to both 6.9 and 6.6 stable [3][4]. The 6.9 backport was
   accepted [5], but for 6.6 Alex Williamson pointed out that the
   fork fix was still reverted — without it, the vfio patches alone
   are unnecessary. Axel withdrew the 6.6 series.

5. 6.6 stable has remained unfixed since July 2024.

== This series ==

This series picks up Axel's withdrawn 6.6 backport of the vfio
refactor patches [4] and adds the missing fork fix on top, completing
the work that was left unfinished. Patches 1-3 are Alex Williamson's
vfio refactor (backported by Axel Rasmussen), patch 4 is the CVE fix
adapted for 6.6 stable.

  1/4 vfio: Create vfio_fs_type with inode per device
  2/4 vfio/pci: Use unmap_mapping_range()
  3/4 vfio/pci: Insert full vma on mmap'd MMIO fault
  4/4 fork: defer linking file vma until vma is fully initialized

== 6.6 stable adaptations ==

Patch 4/4 (fork: defer linking file vma):
 - 6.6 uses vma_iter_bulk_store() which can fail, unlike mainline's
   __mt_dup(). Error handling via goto fail_nomem_vmi_store is preserved.

== Testing ==

CVE reproducer (custom fork/punch_hole stress test, 60s):
 - Unpatched: deadlock in hugetlb_fault within seconds
 - Patched: 2174 forks completed, zero warnings (KASAN+LOCKDEP enabled)

xfstests quick group (672 tests, ext4, virtme-ng):
 - 65 failures, all pre-existing or KASAN-overhead timeouts
 - Zero patch-attributable regressions
 - Leah's 4 specific tests that caused the original revert
   (ext4/303, generic/051, generic/054, generic/069) all pass

VFIO + fork stress test (CONFIG_VFIO=y, hugetlbfs):
 - CVE reproducer with vfio modules active: zero warnings

Yocto CI integration (~87,900 tests per build, LTP+ptest+runtime):
 - No known regressions

dmesg analysis (KASAN, LOCKDEP, PROVE_LOCKING, DEBUG_VM, DEBUG_LIST):
 - Zero memory safety, locking, or VMA state issues across ~38 hours
   of testing

== References ==

[1] Revert discussion:
    https://lore.kernel.org/stable/20240604004751.3883227-1-leah.rumancik@gmail.com/

[2] Leah's backport attempt and vfio discovery:
    https://lore.kernel.org/stable/CACzhbgRjDNkpaQOYsUN+v+jn3E2DVxX0Q4WuQWNjfwEx4Fps6g@mail.gmail.com/T/#u

[3] Axel's vfio series and Alex's feedback:
    https://lore.kernel.org/stable/20240716112530.2562c41b.alex.williamson@redhat.com/T/#u

[4] Axel's 6.6 vfio series (withdrawn):
    https://lore.kernel.org/stable/20240717222429.2011540-1-axelrasmussen@google.com/T/#u

[5] Axel's 6.9 vfio series (accepted):
    https://lore.kernel.org/stable/20240717213339.1921530-1-axelrasmussen@google.com/T/#u

[6] CVE details:
    https://nvd.nist.gov/vuln/detail/CVE-2024-27022

[7] Original report:
    https://lore.kernel.org/linux-mm/20240129161735.6gmjsswx62o4pbja@revolver/T/

[8] Mainline fix:
    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=35e351780fa9d8240dd6f7e4f245f9ea37e96c19


Alex Williamson (3):
  vfio: Create vfio_fs_type with inode per device
  vfio/pci: Use unmap_mapping_range()
  vfio/pci: Insert full vma on mmap'd MMIO fault

Miaohe Lin (1):
  fork: defer linking file vma until vma is fully initialized

 drivers/vfio/device_cdev.c       |   7 +
 drivers/vfio/group.c             |   7 +
 drivers/vfio/pci/vfio_pci_core.c | 271 ++++++++-----------------------
 drivers/vfio/vfio_main.c         |  44 +++++
 include/linux/vfio.h             |   1 +
 include/linux/vfio_pci_core.h    |   2 -
 kernel/fork.c                    |  29 ++--
 7 files changed, 140 insertions(+), 221 deletions(-)

-- 
2.34.1

On Thu,  2 Apr 2026 18:13:07 +0200
tugrul.kukul@est.tech wrote:

> From: Tugrul Kukul <tugrul.kukul@est.tech>
> 
> This series fixes CVE-2024-27022 on 6.6 stable by first backporting the
> necessary vfio refactoring, then applying the fork fix.
> 
> == Background ==
> 
> CVE-2024-27022 is a race condition in dup_mmap() during fork() where a
> file-backed VMA becomes visible through the i_mmap tree before it is
> fully initialized. A concurrent hugetlbfs operation (fallocate/punch_hole)
> can access the VMA with a NULL or inconsistent vma_lock, causing a kernel
> deadlock or WARNING.
> 
> The mainline fix (35e351780fa9, v6.9-rc5) defers linking the file VMA
> into the i_mmap tree until the VMA is fully initialized.
> 
> == Why this hasn't been fixed in 6.6 until now ==
> 
> This CVE has had a troubled backport history on 6.6 stable:
> 
> 1. cec11fa2eb51 - Incomplete backport to 6.6, only moved
>    hugetlb_dup_vma_private() and vm_ops->open() but left
>    vma_iter_bulk_store() and mm->map_count++ in place.
>    Caused xfstests failures.
> 
> 2. dd782da47076 - Sam James reverted the incomplete backport. [1]
> 
> 3. Leah Rumancik attempted a correct backport but discovered it
>    introduced a vfio-pci ordering issue: vm_ops->open() being called
>    before copy_page_range() breaks vfio-pci's zap-then-fault mechanism.
>    Leah withdrew the patch. [2]
> 
> 4. Axel Rasmussen backported Alex Williamson's 3 vfio refactor
>    commits to both 6.9 and 6.6 stable [3][4]. The 6.9 backport was
>    accepted [5], but for 6.6 Alex Williamson pointed out that the
>    fork fix was still reverted — without it, the vfio patches alone
>    are unnecessary. Axel withdrew the 6.6 series.
> 
> 5. 6.6 stable has remained unfixed since July 2024.
> 
> == This series ==
> 
> This series picks up Axel's withdrawn 6.6 backport of the vfio
> refactor patches [4] and adds the missing fork fix on top, completing
> the work that was left unfinished. Patches 1-3 are Alex Williamson's
> vfio refactor (backported by Axel Rasmussen), patch 4 is the CVE fix
> adapted for 6.6 stable.
> 
>   1/4 vfio: Create vfio_fs_type with inode per device
>   2/4 vfio/pci: Use unmap_mapping_range()
>   3/4 vfio/pci: Insert full vma on mmap'd MMIO fault
>   4/4 fork: defer linking file vma until vma is fully initialized
> 
> == 6.6 stable adaptations ==
> 
> Patch 4/4 (fork: defer linking file vma):
>  - 6.6 uses vma_iter_bulk_store() which can fail, unlike mainline's
>    __mt_dup(). Error handling via goto fail_nomem_vmi_store is preserved.
> 
> == Testing ==
> 
> CVE reproducer (custom fork/punch_hole stress test, 60s):
>  - Unpatched: deadlock in hugetlb_fault within seconds
>  - Patched: 2174 forks completed, zero warnings (KASAN+LOCKDEP enabled)
> 
> xfstests quick group (672 tests, ext4, virtme-ng):
>  - 65 failures, all pre-existing or KASAN-overhead timeouts
>  - Zero patch-attributable regressions
>  - Leah's 4 specific tests that caused the original revert
>    (ext4/303, generic/051, generic/054, generic/069) all pass
> 
> VFIO + fork stress test (CONFIG_VFIO=y, hugetlbfs):
>  - CVE reproducer with vfio modules active: zero warnings
> 
> Yocto CI integration (~87,900 tests per build, LTP+ptest+runtime):
>  - No known regressions
> 
> dmesg analysis (KASAN, LOCKDEP, PROVE_LOCKING, DEBUG_VM, DEBUG_LIST):
>  - Zero memory safety, locking, or VMA state issues across ~38 hours
>    of testing
> 
> == References ==
> 
> [1] Revert discussion:
>     https://lore.kernel.org/stable/20240604004751.3883227-1-leah.rumancik@gmail.com/
> 
> [2] Leah's backport attempt and vfio discovery:
>     https://lore.kernel.org/stable/CACzhbgRjDNkpaQOYsUN+v+jn3E2DVxX0Q4WuQWNjfwEx4Fps6g@mail.gmail.com/T/#u
> 
> [3] Axel's vfio series and Alex's feedback:
>     https://lore.kernel.org/stable/20240716112530.2562c41b.alex.williamson@redhat.com/T/#u
> 
> [4] Axel's 6.6 vfio series (withdrawn):
>     https://lore.kernel.org/stable/20240717222429.2011540-1-axelrasmussen@google.com/T/#u
> 
> [5] Axel's 6.9 vfio series (accepted):
>     https://lore.kernel.org/stable/20240717213339.1921530-1-axelrasmussen@google.com/T/#u
> 
> [6] CVE details:
>     https://nvd.nist.gov/vuln/detail/CVE-2024-27022
> 
> [7] Original report:
>     https://lore.kernel.org/linux-mm/20240129161735.6gmjsswx62o4pbja@revolver/T/
> 
> [8] Mainline fix:
>     https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=35e351780fa9d8240dd6f7e4f245f9ea37e96c19
> 
> 
> Alex Williamson (3):
>   vfio: Create vfio_fs_type with inode per device
>   vfio/pci: Use unmap_mapping_range()
>   vfio/pci: Insert full vma on mmap'd MMIO fault
> 
> Miaohe Lin (1):
>   fork: defer linking file vma until vma is fully initialized
> 
>  drivers/vfio/device_cdev.c       |   7 +
>  drivers/vfio/group.c             |   7 +
>  drivers/vfio/pci/vfio_pci_core.c | 271 ++++++++-----------------------
>  drivers/vfio/vfio_main.c         |  44 +++++
>  include/linux/vfio.h             |   1 +
>  include/linux/vfio_pci_core.h    |   2 -
>  kernel/fork.c                    |  29 ++--
>  7 files changed, 140 insertions(+), 221 deletions(-)
> 

For vfio bits:

Acked-by: Alex Williamson <alex@shazbot.org>