In the Linux kernel, the following vulnerability has been resolved:
media: saa7164: fix cleanup on resource allocation failure
saa7164_dev_setup() adds the device to the global saa7164_devlist before
requesting the PCI BAR memory regions.
If get_resources() fails, saa7164_dev_setup() decrements the device count
and returns an error, but leaves the device on saa7164_devlist. The probe
error path then frees the device, leaving a dangling entry on the global
list.
Reuse the existing MMIO mapping error path to remove the device from
saa7164_devlist and decrement the device count before returning.
Also release BAR0 if it was successfully requested but the BAR2 request
fails.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 8.4
AV:L - The bug is reached only from saa7164 PCI probe (saa7164_initdev → saa7164_dev_setup → get_resources()) on a locally attached NXP SAA7164/Hauppauge HVR card; PVR, HTPC, and broadcast systems enumerate that function at boot, udev bind, or PCI/Thunderbolt hotplug, which is a local PCI probe path, not a network or USB protocol path.
AC:L - A 1131:7164 function whose BAR0 or BAR2 cannot be reserved (zero-length BAR, overlap with busy iomem, or BAR2 failing after BAR0 was claimed) makes get_resources() return -EBUSY on every probe, so the dangling saa7164_devlist UAF is deterministic with no race or layout lottery the attacker cannot influence.
PR:N - saa7164_initdev() performs no capability or authentication checks; when a matching PCI function appears, kernel enumeration and udev module autoload run the failing get_resources() path automatically without an OS account or user-namespace privilege.
UI:N - Probe is invoked automatically by the PCI core and udev-driven module autoload on device enumeration; no victim must open a V4L/DVB node, load firmware, or otherwise interact.
S:U - The dangling saa7164_devlist pointer and follow-on use-after-free remain inside the host kernel saa7164 driver and do not cross a VM, IOMMU, or sandbox security boundary.
C:H - After kfree(dev) the global saa7164_devlist still points at the freed saa7164_dev; debugfs seq_start/seq_show and later probes walk that object, so reclaimed heap contents including kernel pointers can be read back — a use-after-free read primitive.
I:H - The next list_add_tail() or list_del() on saa7164_devlist writes next/prev through the freed list node, corrupting whatever slab object reused that allocation and enabling an arbitrary kernel write and control-flow hijack.
A:H - Walking or mutating the dangling saa7164_devlist entry after kfree causes a kernel oops or panic via poisoned-slab dereference or list corruption, fully denying availability.
| Attack Vector |
Local |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - The bug is reached only from saa7164 PCI probe (saa7164_initdev → saa7164_dev_setup → get_resources()) on a locally attached NXP SAA7164/Hauppauge HVR card; PVR, HTPC, and broadcast systems enumerate that function at boot, udev bind, or PCI/Thunderbolt hotplug, which is a local PCI probe path, not a network or USB protocol path.
AC:L - A 1131:7164 function whose BAR0 or BAR2 cannot be reserved (zero-length BAR, overlap with busy iomem, or BAR2 failing after BAR0 was claimed) makes get_resources() return -EBUSY on every probe, so the dangling saa7164_devlist UAF is deterministic with no race or layout lottery the attacker cannot influence.
PR:N - saa7164_initdev() performs no capability or authentication checks; when a matching PCI function appears, kernel enumeration and udev module autoload run the failing get_resources() path automatically without an OS account or user-namespace privilege.
UI:N - Probe is invoked automatically by the PCI core and udev-driven module autoload on device enumeration; no victim must open a V4L/DVB node, load firmware, or otherwise interact.
S:U - The dangling saa7164_devlist pointer and follow-on use-after-free remain inside the host kernel saa7164 driver and do not cross a VM, IOMMU, or sandbox security boundary.
C:H - After kfree(dev) the global saa7164_devlist still points at the freed saa7164_dev; debugfs seq_start/seq_show and later probes walk that object, so reclaimed heap contents including kernel pointers can be read back — a use-after-free read primitive.
I:H - The next list_add_tail() or list_del() on saa7164_devlist writes next/prev through the freed list node, corrupting whatever slab object reused that allocation and enabling an arbitrary kernel write and control-flow hijack.
A:H - Walking or mutating the dangling saa7164_devlist entry after kfree causes a kernel oops or panic via poisoned-slab dereference or list corruption, fully denying availability.
CVSS 3.1