CVE-2026-93206: PCI/proc: Use file_ns_capable() when checking config space read access
In the Linux kernel, the following vulnerability has been resolved:
PCI/proc: Use filenscapable() when checking config space read access
procbuspciread() decides how much of the config space is readable based on capable(CAPSYSADMIN), which checks the credentials of the task calling read(), not the credentials of the process that opened the file.
The sysfs equivalent, pcireadconfig(), has checked the credentials of the opening process since commit de139a339395 ("pci: check caps from sysfs file open to read device dependent config space"), so a privileged process can open the config space file and pass the file descriptor to an unprivileged process (for example, a process running a KVM guest with an assigned device), which can then read the entire config space. The check was subsequently routed through the LSM framework in commit 47970b1b2aa6 ("pci: use securitycapable() when checking capablities during config space read") and converted to the dedicated helper in commit ab0fa82b2df9 ("pci-sysfs: use proper file capability helper function").
Thus, the two interfaces check the same capability against different credentials. Checking the credentials of the task calling read() makes the outcome depend on who reads rather than who opened, so the restriction is bypassed whenever a more privileged process reads through the descriptor. Checking the credentials recorded in file->fcred settles the decision at open() time and ties it to the file, where it cannot change with the caller.
Use filenscapable() to check CAPSYSADMIN against the credentials in effect when the file was opened, bringing the procfs interface in line with the sysfs behaviour.
As a result, a file descriptor opened by a privileged process and passed to an unprivileged one now allows the entire config space to be read through procfs, matching sysfs.
Affected Software
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Systems are exposed when a privileged process opens a PCI configuration-space file through procfs and passes that file descriptor to an unprivileged process. The example described is a process running a KVM guest with an assigned device.
What does an attacker need to exploit it?
The attacker needs access to a PCI configuration-space file descriptor that was opened by a process with CAP_SYS_ADMIN. Once it receives that descriptor, an unprivileged process can read the entire configuration space through the affected procfs interface.
What can be done if the kernel fix cannot be deployed immediately?
Avoid passing procfs PCI configuration-space file descriptors from privileged processes to unprivileged processes. In particular, review designs that hand such descriptors to workloads associated with assigned PCI devices.