https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 28 Sep 2026 23:12:52 +0000 https://vulnerability.circl.lu/vuln/bell-cve-2026-93206 <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> https://vulnerability.circl.lu/vuln/bell-cve-2026-93206 https://vulnerability.circl.lu/vuln/fkie_cve-2026-93206 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>PCI/proc: Use file_ns_capable() when checking config space read access</p> <p>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.</p> <p>The sysfs equivalent, pci_read_config(), has checked the credentials of the opening process since commit de139a339395 (&#34;pci: check caps from sysfs file open to read device dependent config space&#34;), 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 (&#34;pci: use security_capable() when checking capablities during config space read&#34;) and converted to the dedicated helper in commit ab0fa82b2df9 (&#34;pci-sysfs: use proper file capability helper function&#34;).</p> <p>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-&gt;f_cred settles the decision at open() time and ties it to the file, where it cannot change wi…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>PCI/proc: Use file_ns_capable() when checking config space read access</p> <p>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.</p> <p>The sysfs equivalent, pci_read_config(), has checked the credentials of the opening process since commit de139a339395 (&#34;pci: check caps from sysfs file open to read device dependent config space&#34;), 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 (&#34;pci: use security_capable() when checking capablities during config space read&#34;) and converted to the dedicated helper in commit ab0fa82b2df9 (&#34;pci-sysfs: use proper file capability helper function&#34;).</p> <p>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-&gt;f_cred settles the decision at open() time and ties it to the file, where it cannot change wi…</p> https://vulnerability.circl.lu/vuln/fkie_cve-2026-93206 https://vulnerability.circl.lu/vuln/ghsa-fjc2-7frc-hj2c <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>PCI/proc: Use file_ns_capable() when checking config space read access</p> <p>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.</p> <p>The sysfs equivalent, pci_read_config(), has checked the credentials of the opening process since commit de139a339395 (&#34;pci: check caps from sysfs file open to read device dependent config space&#34;), 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 (&#34;pci: use security_capable() when checking capablities during config space read&#34;) and converted to the dedicated helper in commit ab0fa82b2df9 (&#34;pci-sysfs: use proper file capability helper function&#34;).</p> <p>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-&gt;f_cred settles the decision at open() time and ties it to the file, where it cannot change wi…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>PCI/proc: Use file_ns_capable() when checking config space read access</p> <p>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.</p> <p>The sysfs equivalent, pci_read_config(), has checked the credentials of the opening process since commit de139a339395 (&#34;pci: check caps from sysfs file open to read device dependent config space&#34;), 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 (&#34;pci: use security_capable() when checking capablities during config space read&#34;) and converted to the dedicated helper in commit ab0fa82b2df9 (&#34;pci-sysfs: use proper file capability helper function&#34;).</p> <p>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-&gt;f_cred settles the decision at open() time and ties it to the file, where it cannot change wi…</p> https://vulnerability.circl.lu/vuln/ghsa-fjc2-7frc-hj2c https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-93206 <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 246 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: PCI/proc: Use file_ns_capable() when checking config space read access 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 (&#34;pci: check caps from sysfs file open to read device dependent config space&#34;), 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 (&#34;pci: use security_capable() when checking capablities during config space read&#34;) and converted to the dedicated helper in commit ab0fa82b2df9 (&#34;pci-sysfs: use proper file capability helper function&#34;). 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-&gt;f_cred settles the decision at open() time and ties it to the file, where it cannot change with t…</p> <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 246 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: PCI/proc: Use file_ns_capable() when checking config space read access 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 (&#34;pci: check caps from sysfs file open to read device dependent config space&#34;), 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 (&#34;pci: use security_capable() when checking capablities during config space read&#34;) and converted to the dedicated helper in commit ab0fa82b2df9 (&#34;pci-sysfs: use proper file capability helper function&#34;). 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-&gt;f_cred settles the decision at open() time and ties it to the file, where it cannot change with t…</p> https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-93206 https://vulnerability.circl.lu/vuln/wid-sec-w-2026-3579 <p>Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Zustand herbeizuführen oder nicht näher spezifizierten Angriff durchzuführen.</p> <p>Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Zustand herbeizuführen oder nicht näher spezifizierten Angriff durchzuführen.</p> https://vulnerability.circl.lu/vuln/wid-sec-w-2026-3579