Re: [PATCH v2 6/6] vfio: selftests: Add tests to validate SR-IOV UAPI

[David Matlack <dmatlack@google.com>]

On 2026-01-06 11:47 AM, Raghavendra Rao Ananta wrote:
> On Thu, Dec 18, 2025 at 3:26 PM David Matlack <dmatlack@google.com> wrote:
> >
> > On 2025-12-10 06:14 PM, Raghavendra Rao Ananta wrote:
> > > Add a selfttest, vfio_pci_sriov_uapi_test.c, to validate the
> > > SR-IOV UAPI, including the following cases, iterating over
> > > all the IOMMU modes currently supported:
> > >  - Setting correct/incorrect/NULL tokens during device init.
> > >  - Close the PF device immediately after setting the token.
> > >  - Change/override the PF's token after device init.
> > >
> > > Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> >
> > I hit the following kernel NULL pointer dereference after running the
> > new test a few times (nice!).
> >
> > Repro:
> >
> >   $ tools/testing/selftests/vfio/scripts/setup.sh 0000:16:00.1
> >   $ tools/testing/selftests/vfio/vfio_pci_sriov_uapi_test 0000:16:00.1
> >   $ tools/testing/selftests/vfio/scripts/cleanup.sh
> >   ... repeat ...
> >
> > The panic:
> >
> > [  553.245784][T27601] vfio-pci 0000:1a:00.0: probe with driver vfio-pci failed with error -22
> > [  553.256622][T27601] vfio-pci 0000:1a:00.0: probe with driver vfio-pci failed with error -22
> > [  574.857650][T27935] BUG: kernel NULL pointer dereference, address: 0000000000000008
> > [  574.865322][T27935] #PF: supervisor read access in kernel mode
> > [  574.871175][T27935] #PF: error_code(0x0000) - not-present page
> > [  574.877021][T27935] PGD 4116e63067 P4D 40fb0a3067 PUD 409597f067 PMD 0
> > [  574.883654][T27935] Oops: Oops: 0000 [#1] SMP NOPTI
> > [  574.888551][T27935] CPU: 100 UID: 0 PID: 27935 Comm: vfio_pci_sriov_ Tainted: G S      W           6.18.0-smp-DEV #1 NONE
> > [  574.899600][T27935] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN
> > [  574.905104][T27935] Hardware name: Google Izumi-EMR/izumi, BIOS 0.20250801.2-0 08/25/2025
> > [  574.913289][T27935] RIP: 0010:rb_insert_color+0x44/0x110
> > [  574.918623][T27935] Code: cc cc 48 89 cf 48 83 cf 01 48 89 3a 48 89 38 48 8b 01 48 89 cf 48 83 e0 fc 48 89 01 74 d7 48 8b 08 f6 c1 01 0f 85 c1 00 00 00 <48> 8b 51 08 48 39 c2 74 0c 48 85 d2 74 4f f6 02 01 74 c5 eb 48 48
> > [  574.938080][T27935] RSP: 0018:ff85113dcdd6bb08 EFLAGS: 00010046
> > [  574.944013][T27935] RAX: ff3f257594a99e80 RBX: ff3f25758af490c0 RCX: 0000000000000000
> > [  574.951857][T27935] RDX: 0000000000001a00 RSI: ff3f25360038eb70 RDI: ff3f2536658bbee0
> > [  574.959702][T27935] RBP: ff3f25360038ea00 R08: 0000000000000002 R09: ff85113dcdd6badc
> > [  574.967544][T27935] R10: ff3f257590ab8000 R11: ffffffffa78210a0 R12: ff3f2536658bbea0
> > [  574.975387][T27935] R13: 0000000000000286 R14: ff3f25758af49000 R15: ff3f25360038eb78
> > [  574.983230][T27935] FS:  00000000223403c0(0000) GS:ff3f25b4d4d83000(0000) knlGS:0000000000000000
> > [  574.992032][T27935] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [  574.998488][T27935] CR2: 0000000000000008 CR3: 00000040fa254005 CR4: 0000000000f71ef0
> > [  575.006332][T27935] PKRU: 55555554
> > [  575.009753][T27935] Call Trace:
> > [  575.012919][T27935]  <TASK>
> > [  575.015730][T27935]  intel_iommu_probe_device+0x4c9/0x7b0
> > [  575.021153][T27935]  __iommu_probe_device+0x101/0x4c0
> > [  575.026231][T27935]  iommu_bus_notifier+0x37/0x100
> > [  575.031046][T27935]  blocking_notifier_call_chain+0x53/0xd0
> > [  575.036634][T27935]  bus_notify+0x99/0xc0
> > [  575.040666][T27935]  device_add+0x252/0x470
> > [  575.044872][T27935]  pci_device_add+0x414/0x5c0
> > [  575.049429][T27935]  pci_iov_add_virtfn+0x2f2/0x3e0
> > [  575.054326][T27935]  sriov_add_vfs+0x33/0x70
> > [  575.058613][T27935]  sriov_enable+0x2fc/0x490
> > [  575.062992][T27935]  vfio_pci_core_sriov_configure+0x16c/0x210
> > [  575.068843][T27935]  sriov_numvfs_store+0xc4/0x190
> > [  575.073652][T27935]  kernfs_fop_write_iter+0xfe/0x180
> > [  575.078724][T27935]  vfs_write+0x2d0/0x430
> > [  575.082846][T27935]  ksys_write+0x7f/0x100
> > [  575.086965][T27935]  do_syscall_64+0x6f/0x940
> > [  575.091339][T27935]  ? arch_exit_to_user_mode_prepare+0x9/0xb0
> > [  575.097193][T27935]  entry_SYSCALL_64_after_hwframe+0x76/0x7e

I think this is a use-after-free.

The VF used in this test matches quirk_intel_e2000_no_ats() which means
that ATS gets disabled (pdev->ats_cap = 0) via quirk after the device is
set up.

 drivers/pci/quirks.c:

 5651 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1457, quirk_intel_e2000_no_ats);

The issue is this quirk is applied after the Intel IOMMU driver is
notified about the device.

So during intel_iommu_probe_device(), the Intel IOMMU driver sees that
ATS is enabled, and adds the device to the device rbtree:

 drivers/iommu/intel/iommu.c:

 3765 static struct iommu_device *intel_iommu_probe_device(struct device *dev)
 3766 {
 ...
 3826         if (pdev && pci_ats_supported(pdev)) {
 3827                 pci_prepare_ats(pdev, VTD_PAGE_SHIFT);
 3828                 ret = device_rbtree_insert(iommu, info);
 3829                 if (ret)
 3830                         goto free;
 3831         }
 ...
 3858 }


Then ATS is disabled via quirk:

 drivers/pci/iov.c:

 346 int pci_iov_add_virtfn(struct pci_dev *dev, int id)
 347 {
 ...
 383
 384         pci_device_add(virtfn, virtfn->bus);  <======= notifies Intel IOMMU
 385         rc = pci_iov_sysfs_link(dev, virtfn, id);
 386         if (rc)
 387                 goto failed1;
 388
 389         pci_bus_add_device(virtfn);  <==== Disables ATS via pci_fixup_final
 390
 391         return 0;
 ...
 401 }

Then later when the VF is destroyed (SR-IOV disabled on the PF), the
Intel IOMMU sees that ATS is disabled and does not remove the device
from its rbtree.

 drivers/iommu/intel/iommu.c:

 3889 static void intel_iommu_release_device(struct device *dev)
 3890 {
 ...
 3903         if (dev_is_pci(dev) && pci_ats_supported(to_pci_dev(dev)))
 3904                 device_rbtree_remove(info);
 ...
 3913         kfree(info);   <======= info is still reachable from device rbtree
 3914 }