All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
	Manivannan Sadhasivam <mani@kernel.org>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Kees Cook <kees@kernel.org>,
	linux-pci@vger.kernel.org
Subject: [PATCH] PCI/proc: Use file_ns_capable() when checking config space read access
Date: Mon, 20 Jul 2026 20:41:45 +0000	[thread overview]
Message-ID: <20260720204145.1500105-1-kwilczynski@kernel.org> (raw)

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.

Therefore, 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.

Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
---
 drivers/pci/proc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c
index 71ad289fcb8e..690a5625fcb4 100644
--- a/drivers/pci/proc.c
+++ b/drivers/pci/proc.c
@@ -39,7 +39,7 @@ static ssize_t proc_bus_pci_read(struct file *file, char __user *buf,
 	 * undefined locations (think of Intel PIIX4 as a typical example).
 	 */
 
-	if (capable(CAP_SYS_ADMIN))
+	if (file_ns_capable(file, &init_user_ns, CAP_SYS_ADMIN))
 		size = dev->cfg_size;
 	else if (dev->hdr_type == PCI_HEADER_TYPE_CARDBUS)
 		size = 128;
-- 
2.55.0


             reply	other threads:[~2026-07-20 20:41 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-20 20:41 Krzysztof Wilczyński [this message]
2026-07-20 20:59 ` [PATCH] PCI/proc: Use file_ns_capable() when checking config space read access sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260720204145.1500105-1-kwilczynski@kernel.org \
    --to=kwilczynski@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=helgaas@kernel.org \
    --cc=kees@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=mani@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.