CVE-2025-21976

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local

The vulnerability is reached through local interfaces only — opening and mmap'ing the `/dev/fbN` character device and the local/administrative device-removal path (sysfs unbind, module unload, or VMBus rescind of the guest's synthetic video device). No network or adjacent-network vector exists for hyperv_fb.

AC:LAttack complexity, low

There is no race to win: a process simply holds an mmap of `/dev/fb0`, and the premature `vfree()`/`kvfree()` in `hvfb_remove()` deterministically leaves that mapping and the `info->pagerefs` array pointing at freed memory. Grooming the recycled pages afterwards is under the attacker's control via ordinary allocation pressure.

PR:LPrivileges required, low

The party that gains the freed-memory read/write primitive only needs to open and mmap the framebuffer device, which unprivileged seat/console users (logind ACLs), `video`-group members, and graphics-domain processes on embedded/Android-style systems routinely can do. No CAP_SYS_ADMIN is needed to hold the mapping that survives the teardown.

UI:NUser interaction, none

The removal that triggers the free is a device/administrative event — Hyper-V host-side rescind of the video VMBus device, driver reload during a package update, or automated unbind — not an action by a victim user, and the attacking process merely has to be mapped when it occurs. This matches the treatment of the identical fbdev hot-unplug-while-mapped class.

S:UScope, unchanged

The corrupted resources (vmalloc pages, the deferred-I/O pageref array, the leaked `fb_info`) are all kernel memory managed by the same security authority as the vulnerable driver. No hypervisor, IOMMU, or sandbox boundary is crossed.

C:HConfidentiality impact, high

After `vfree(par->dio_vp)` the surviving userspace mapping still points at pages handed back to the page allocator, so the attacker can read whatever kernel data those pages are subsequently reused for — slab objects, page tables, credentials — an effectively arbitrary kernel memory disclosure.

I:HIntegrity impact, high

The same surviving mapping is writable, giving a page-granularity write primitive into recycled kernel memory, and write faults additionally corrupt the kvfree'd `info->pagerefs` array and lock a destroyed mutex. That combination is a classic path to heap/page-table corruption and control-flow hijack.

A:HAvailability impact, high

Unbind with the framebuffer in use produces a `WARN_ON` in `framebuffer_release()` (fatal under panic_on_warn) plus an `fb_info` leak, and subsequent access from the still-open fd faults on freed vmalloc memory, walks a freed pageref array, and locks a destroyed mutex — resulting in oops/panic.