CVE-2026-98142 in Linux
Summary
by MITRE • 09/25/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/cirrus-qemu: Validate BAR0 size during probe
The `cirrus-qemu` driver relies on `CIRRUS_VRAM_SIZE` (4 MB) to validate framebuffer sizes. However, during PCI probe, the driver mapped BAR0 without verifying that its size matches `CIRRUS_VRAM_SIZE`.
If a PCI device with a BAR0 smaller than 4 MB is bound to the driver, the mapped VRAM will be smaller than expected. Because validation checks assume 4 MB VRAM, framebuffers larger than the mapped memory can be created.
When the display plane is updated (e.g. during release), `cirrus_primary_plane_helper_atomic_update()` copies the framebuffer to VRAM using `drm_fb_memcpy()`. Writing past the end of the mapped I/O memory causes a supervisor write page fault:
BUG: unable to handle page fault for address: ffffc9000389c000 ... RIP: 0010:memcpy_toio+0x7c/0xe0 arch/x86/lib/iomem.c:110 ... Call Trace: <TASK> iosys_map_memcpy_to include/linux/iosys-map.h:285 [inline]
drm_fb_memcpy+0x325/0x5d0 drivers/gpu/drm/drm_format_helper.c:442 cirrus_primary_plane_helper_atomic_update+0x98a/0xb00 drivers/gpu/drm/tiny/cirrus-qemu.c:358 drm_atomic_helper_commit_planes+0x626/0xea0 drivers/gpu/drm/drm_atomic_helper.c:3038 drm_atomic_helper_commit_tail+0x60/0x510 drivers/gpu/drm/drm_atomic_helper.c:1989 commit_tail+0x2b1/0x3c0 drivers/gpu/drm/drm_atomic_helper.c:2074 drm_atomic_helper_commit+0xa77/0xb10 drivers/gpu/drm/drm_atomic_helper.c:2312
Fix this by validating in `cirrus_pci_probe()` that the PCI BAR0 resource is not less than `CIRRUS_VRAM_SIZE`, returning `-ENODEV` if it is less.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/25/2026
The cirrus-qemu driver within the Linux kernel contains a critical validation flaw during its initialization phase, specifically in the pci probe routine. This vulnerability stems from an assumption that the PCI Base Address Register zero (BAR0) will always provide at least 4 megabytes of video random access memory (VRAM), as defined by the constant CIRRUS_VRAM_SIZE. The driver maps this BAR0 region to kernel virtual memory for subsequent framebuffer operations but fails to verify that the actual size reported by the hardware matches or exceeds this expected threshold. This oversight creates a scenario where devices with smaller BAR0 allocations can be successfully bound to the driver, leading to an inconsistent state between the allocated VRAM and the expectations of the display subsystem.
When a PCI device with a BAR0 size smaller than 4 megabytes is attached, the kernel maps only the available memory region. However, subsequent framebuffer creation logic continues to operate under the assumption that the full 4-megabyte space is accessible. This discrepancy allows for the allocation and configuration of framebuffers that exceed the actual mapped I/O memory boundaries. The vulnerability manifests when the display plane undergoes an update operation, such as during a release or atomic commit sequence. At this stage, the function cirrus_primary_plane_helper_atomic_update invokes drm_fb_memcpy to transfer framebuffer data into VRAM using memcpy_toio.
Because the target address range extends beyond the physically mapped BAR0 region, the kernel attempts to write to unmapped I/O memory space. This action triggers a supervisor write page fault, resulting in an immediate crash of the system or the specific driver context. The call trace indicates that the failure occurs deep within the atomic helper commit path, highlighting how standard display update routines can inadvertently exploit this boundary violation. Such out-of-bounds writes not only cause denial of service through kernel panics but also represent a potential vector for memory corruption if the fault handling mechanisms are bypassed or misconfigured in certain environments.
From a classification perspective, this vulnerability aligns with CWE-125, which describes Out-of-Bounds Read vulnerabilities, although in this specific execution path involving writes via memcpy_toio, it effectively functions as an out-of-bounds write scenario leading to memory corruption and system instability. In the context of the MITRE ATT&CK framework, this flaw relates to techniques that exploit improper input validation during resource initialization, potentially allowing for denial of service attacks against virtualized environments relying on Cirrus logic emulation. The lack of size verification at probe time is a classic example of trusting hardware-reported values without sufficient sanitization or bounds checking relative to driver-specific requirements.
To mitigate this vulnerability, the fix involves adding explicit size validation within the cirrus_pci_probe function before mapping resources. By comparing the resource length against CIRRUS_VRAM_SIZE and returning -ENODEV if the condition is not met, the driver ensures that only devices with sufficient VRAM are bound to it. This prevents the creation of oversized framebuffers and eliminates the risk of writing past mapped memory boundaries. System administrators should ensure their kernels are updated to include this patch, particularly in virtualized environments where guest operating systems interact with emulated Cirrus Logic graphics hardware. Regular auditing of PCI driver probe routines for similar assumptions about resource sizes can further harden kernel code against such initialization flaws.