| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <aYUQ_HkDJU9kjsUl@google.com>
Date: Thu, 5 Feb 2026 21:51:56 +0000
From: David Matlack <dmatlack@...gle.com>
To: Raghavendra Rao Ananta <rananta@...gle.com>
Cc: Alex Williamson <alex@...zbot.org>,
Alex Williamson <alex.williamson@...hat.com>,
Josh Hilke <jrhilke@...gle.com>, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org, iommu@...ts.linux.dev,
Bjorn Helgaas <bhelgaas@...gle.com>, linux-pci@...r.kernel.org,
David Woodhouse <dwmw2@...radead.org>,
Lu Baolu <baolu.lu@...ux.intel.com>,
Samiullah Khawaja <skhawaja@...gle.com>
Subject: Re: [PATCH v2 6/6] vfio: selftests: Add tests to validate SR-IOV UAPI
On 2026-01-06 11:47 AM, Raghavendra Rao Ananta wrote:
> On Thu, Dec 18, 2025 at 3:26 PM David Matlack <dmatlack@...gle.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@...gle.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 }
Powered by blists - more mailing lists