CVE-2026-93206

What the bug is

proc_bus_pci_read() decides how much of the config space is readable based on capable(CAP_SYS_ADMIN), which checks the credentials of the task calling read(), not the credentials of the process that opened the file. The sysfs equivalent, pci_read_config(), 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 security_capable() 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->f_cred settles the decision at open() time and ties it to the file, where it cannot change with the caller. Use file_ns_capable() to check CAP_SYS_ADMIN 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.

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

drivers/pci/proc.c

What this is

PCI SUBSYSTEMMAINTAINERS section matched on drivers/pci/ · linux-pci@vger.kernel.org · Supported

Check it on the machine

grep -wE 'CONFIG_PCI|CONFIG_PROC_FS' /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

Show whether Debian builds this, per release

Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.

• bookwormy
• trixieYnot built on armel/rpi
• forky, sid, bookworm · linux-6.12y

y

built into the kernel image on every flavour - only a patch removes it

Y

built in where it is built at all; some flavours do not build it

Build switches

CONFIG_PCI, CONFIG_PROC_FS

Reads as

all on means the file is compiled; any one off means it is not.

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Signals

Published

2026-09-24 (24 days ago)source

CVSS

no vector published, unrated

Attack vector

not published

EPSS

0.19%, higher than 8.0% of all CVEssource

CISA KEV

not listedthe KEV catalogue

Debian urgency

not yet assignedsource

Subsystem

drivers/pci

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
2.6.12	5.10.270	8a3a54aa3e65
2.6.12	5.15.221	5c7ab4ca66f0
2.6.12	6.1.188	53407535d49e
2.6.12	6.6.157	e7730acd6a01
2.6.12	6.12.109	77272b7fd0e4
2.6.12	6.18.50	c2d4174f4924
2.6.12	7.2.4	6351e9407632
2.6.12	7.3	f82f53e75eff

Debian advisories