In the Linux kernel, the following vulnerability has been resolved: PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV Before disabling SR-IOV via config space accesses to the parent PF, sriov_disable() first removes the PCI devices representing the VFs. Since commit 9d16947b7583 ("PCI: Add global pci_lock_rescan_remove()") such removal operations are serialized against concurrent remove and rescan using the pci_rescan_remove_lock. No such locking was ever added in sriov_disable() however. In particular when commit 18f9e9d150fc ("PCI/IOV: Factor out sriov_add_vfs()") factored out the PCI device removal into sriov_del_vfs() there was still no locking around the pci_iov_remove_virtfn() calls. On s390 the lack of serialization in sriov_disable() may cause double remove and list corruption with the below (amended) trace being observed: PSW: 0704c00180000000 0000000c914e4b38 (klist_put+56) GPRS: 000003800313fb48 0000000000000000 0000000100000001 0000000000000001 00000000f9b520a8 0000000000000000 0000000000002fbd 00000000f4cc9480 0000000000000001 0000000000000000 0000000000000000 0000000180692828 00000000818e8000 000003800313fe2c 000003800313fb20 000003800313fad8 #0 [3800313fb20] device_del at c9158ad5c #1 [3800313fb88] pci_remove_bus_device at c915105ba #2 [3800313fbd0] pci_iov_remove_virtfn at c9152f198 #3 [3800313fc28] zpci_iov_remove_virtfn at c90fb67c0 #4 [3800313fc60] zpci_bus_remove_device at c90fb6104 #5 [3800313fca0] __zpci_event_availability at c90fb3dca #6 [3800313fd08] chsc_process_sei_nt0 at c918fe4a2 #7 [3800313fd60] crw_collect_info at c91905822 #8 [3800313fe10] kthread at c90feb390 #9 [3800313fe68] __ret_from_fork at c90f6aa64 #10 [3800313fe98] ret_from_fork at c9194f3f2. This is because in addition to sriov_disable() removing the VFs, the platform also generates hot-unplug events for the VFs. This being the reverse operation to the hotplug events generated by sriov_enable() and handled via pdev->no_vf_scan. And while the event processing takes pci_rescan_remove_lock and checks whether the struct pci_dev still exists, the lack of synchronization makes this checking racy. Other races may also be possible of course though given that this lack of locking persisted so long observable races seem very rare. Even on s390 the list corruption was only observed with certain devices since the platform events are only triggered by config accesses after the removal, so as long as the removal finished synchronously they would not race. Either way the locking is missing so fix this by adding it to the sriov_del_vfs() helper. Just like PCI rescan-remove, locking is also missing in sriov_add_vfs() including for the error case where pci_stop_and_remove_bus_device() is called without the PCI rescan-remove lock being held. Even in the non-error case, adding new PCI devices and buses should be serialized via the PCI rescan-remove lock. Add the necessary locking.

The remote Debian 11 host has packages installed that are affected by multiple vulnerabilities as referenced in the dla-4404 advisory.

    -------------------------------------------------------------------------     Debian LTS Advisory DLA-4404-1                debian-lts@lists.debian.org     https://www.debian.org/lts/security/                        Ben Hutchings     December 12, 2025                             https://wiki.debian.org/LTS
    -------------------------------------------------------------------------

    Package        : linux     Version        : 5.10.247-1     CVE ID         : CVE-2023-53498 CVE-2024-47666 CVE-2024-50143 CVE-2024-57947                      CVE-2025-21861 CVE-2025-21887 CVE-2025-22058 CVE-2025-23143                      CVE-2025-38678 CVE-2025-39866 CVE-2025-39869 CVE-2025-39876                      CVE-2025-39883 CVE-2025-39885 CVE-2025-39907 CVE-2025-39911                      CVE-2025-39913 CVE-2025-39923 CVE-2025-39937 CVE-2025-39945                      CVE-2025-39949 CVE-2025-39951 CVE-2025-39953 CVE-2025-39955                      CVE-2025-39964 CVE-2025-39967 CVE-2025-39968 CVE-2025-39969                      CVE-2025-39970 CVE-2025-39971 CVE-2025-39972 CVE-2025-39973                      CVE-2025-39980 CVE-2025-39985 CVE-2025-39986 CVE-2025-39987                      CVE-2025-39993 CVE-2025-39994 CVE-2025-39995 CVE-2025-39996                      CVE-2025-39998 CVE-2025-40001 CVE-2025-40006 CVE-2025-40011                      CVE-2025-40018 CVE-2025-40019 CVE-2025-40020 CVE-2025-40021                      CVE-2025-40022 CVE-2025-40026 CVE-2025-40027 CVE-2025-40029                      CVE-2025-40030 CVE-2025-40035 CVE-2025-40042 CVE-2025-40044                      CVE-2025-40048 CVE-2025-40049 CVE-2025-40053 CVE-2025-40055                      CVE-2025-40070 CVE-2025-40078 CVE-2025-40081 CVE-2025-40083                      CVE-2025-40087 CVE-2025-40088 CVE-2025-40105 CVE-2025-40106                      CVE-2025-40109 CVE-2025-40111 CVE-2025-40115 CVE-2025-40116                      CVE-2025-40118 CVE-2025-40121 CVE-2025-40125 CVE-2025-40127                      CVE-2025-40134 CVE-2025-40140 CVE-2025-40153 CVE-2025-40154                      CVE-2025-40167 CVE-2025-40173 CVE-2025-40178 CVE-2025-40183                      CVE-2025-40186 CVE-2025-40187 CVE-2025-40188 CVE-2025-40190                      CVE-2025-40194 CVE-2025-40197 CVE-2025-40198 CVE-2025-40200                      CVE-2025-40204 CVE-2025-40205 CVE-2025-40211 CVE-2025-40219                      CVE-2025-40220 CVE-2025-40223 CVE-2025-40231 CVE-2025-40233                      CVE-2025-40240 CVE-2025-40243 CVE-2025-40244 CVE-2025-40248                      CVE-2025-40254 CVE-2025-40257 CVE-2025-40258 CVE-2025-40259                      CVE-2025-40261 CVE-2025-40262 CVE-2025-40263 CVE-2025-40264                      CVE-2025-40269 CVE-2025-40271 CVE-2025-40273 CVE-2025-40275                      CVE-2025-40277 CVE-2025-40278 CVE-2025-40280 CVE-2025-40281                      CVE-2025-40282 CVE-2025-40283 CVE-2025-40304 CVE-2025-40306                      CVE-2025-40308 CVE-2025-40309 CVE-2025-40312 CVE-2025-40315                      CVE-2025-40317 CVE-2025-40319 CVE-2025-40321 CVE-2025-40322                      CVE-2025-40324 CVE-2025-40331 CVE-2025-40342     Debian Bug     : 1107479 1114557

    Several vulnerabilities have been discovered in the Linux kernel that     may lead to a privilege escalation, denial of service or information     leaks.

    For Debian 11 bullseye, these problems have been fixed in version     5.10.247-1.  This version additionally includes many more bug fixes     from stable updates 5.10.245-5.10.247.  The broken pktcdvd driver has     also been disabled.

    We recommend that you upgrade your linux packages.

    For the detailed security status of linux please refer to     its security tracker page at:
    https://security-tracker.debian.org/tracker/linux

    Further information about Debian LTS security advisories, how to apply     these updates to your system and frequently asked questions can be     found at: https://wiki.debian.org/LTS     Attachment:
    signature.asc     Description: PGP signature

Tenable has extracted the preceding description block directly from the Debian security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV Before disabling SR-IOV via config     space accesses to the parent PF, sriov_disable() first removes the PCI devices representing the VFs. Since     commit 9d16947b7583 (PCI: Add global pci_lock_rescan_remove()) such removal operations are serialized     against concurrent remove and rescan using the pci_rescan_remove_lock. No such locking was ever added in     sriov_disable() however. In particular when commit 18f9e9d150fc (PCI/IOV: Factor out sriov_add_vfs())     factored out the PCI device removal into sriov_del_vfs() there was still no locking around the     pci_iov_remove_virtfn() calls. On s390 the lack of serialization in sriov_disable() may cause double     remove and list corruption with the below (amended) trace being observed: PSW: 0704c00180000000     0000000c914e4b38 (klist_put+56) GPRS: 000003800313fb48 0000000000000000 0000000100000001 0000000000000001     00000000f9b520a8 0000000000000000 0000000000002fbd 00000000f4cc9480 0000000000000001 0000000000000000     0000000000000000 0000000180692828 00000000818e8000 000003800313fe2c 000003800313fb20 000003800313fad8 #0     [3800313fb20] device_del at c9158ad5c #1 [3800313fb88] pci_remove_bus_device at c915105ba #2 [3800313fbd0]     pci_iov_remove_virtfn at c9152f198 #3 [3800313fc28] zpci_iov_remove_virtfn at c90fb67c0 #4 [3800313fc60]     zpci_bus_remove_device at c90fb6104 #5 [3800313fca0] __zpci_event_availability at c90fb3dca #6     [3800313fd08] chsc_process_sei_nt0 at c918fe4a2 #7 [3800313fd60] crw_collect_info at c91905822 #8     [3800313fe10] kthread at c90feb390 #9 [3800313fe68] __ret_from_fork at c90f6aa64 #10 [3800313fe98]     ret_from_fork at c9194f3f2. This is because in addition to sriov_disable() removing the VFs, the platform     also generates hot-unplug events for the VFs. This being the reverse operation to the hotplug events     generated by sriov_enable() and handled via pdev->no_vf_scan. And while the event processing takes     pci_rescan_remove_lock and checks whether the struct pci_dev still exists, the lack of synchronization     makes this checking racy. Other races may also be possible of course though given that this lack of     locking persisted so long observable races seem very rare. Even on s390 the list corruption was only     observed with certain devices since the platform events are only triggered by config accesses after the     removal, so as long as the removal finished synchronously they would not race. Either way the locking is     missing so fix this by adding it to the sriov_del_vfs() helper. Just like PCI rescan-remove, locking is     also missing in sriov_add_vfs() including for the error case where pci_stop_and_remove_bus_device() is     called without the PCI rescan-remove lock being held. Even in the non-error case, adding new PCI devices     and buses should be serialized via the PCI rescan-remove lock. Add the necessary locking. (CVE-2025-40219)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Severity
296481	SUSE SLES15 Security Update : kernel (SUSE-SU-2026:0278-1)	Nessus	SuSE Local Security Checks	high
278560	Oracle Linux 7 / 8 : Unbreakable Enterprise kernel (ELSA-2025-28049)	Nessus	Oracle Linux Local Security Checks	medium
278559	Debian dla-4404 : ata-modules-5.10.0-35-armmp-di - security update	Nessus	Debian Local Security Checks	high
277481	Linux Distros Unpatched Vulnerability : CVE-2025-40219	Nessus	Misc.	medium

Detections

Analytics

CVE-2025-40219

medium

Tenable Plugins

high

medium

high

medium