CVE-2025-21953 in Linux
Summary
by MITRE • 04/01/2025
In the Linux kernel, the following vulnerability has been resolved:
net: mana: cleanup mana struct after debugfs_remove()
When on a MANA VM hibernation is triggered, as part of hibernate_snapshot(), mana_gd_suspend() and mana_gd_resume() are called. If during this mana_gd_resume(), a failure occurs with HWC creation, mana_port_debugfs pointer does not get reinitialized and ends up pointing to older, cleaned-up dentry. Further in the hibernation path, as part of power_down(), mana_gd_shutdown() is triggered. This call, unaware of the failures in resume, tries to cleanup the already cleaned up mana_port_debugfs value and hits the following bug:
[ 191.359296] mana 7870:00:00.0: Shutdown was called
[ 191.359918] BUG: kernel NULL pointer dereference, address: 0000000000000098
[ 191.360584] #PF: supervisor write access in kernel mode
[ 191.361125] #PF: error_code(0x0002) - not-present page
[ 191.361727] PGD 1080ea067 P4D 0
[ 191.362172] Oops: Oops: 0002 [#1] SMP NOPTI
[ 191.362606] CPU: 11 UID: 0 PID: 1674 Comm: bash Not tainted 6.14.0-rc5+ #2
[ 191.363292] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/21/2024
[ 191.364124] RIP: 0010:down_write+0x19/0x50
[ 191.364537] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb e8 de cd ff ff 31 c0 ba 01 00 00 00 48 0f b1 13 75 16 65 48 8b 05 88 24 4c 6a 48 89 43 08 48 8b 5d
[ 191.365867] RSP: 0000:ff45fbe0c1c037b8 EFLAGS: 00010246
[ 191.366350] RAX: 0000000000000000 RBX: 0000000000000098 RCX: ffffff8100000000
[ 191.366951] RDX: 0000000000000001 RSI: 0000000000000064 RDI: 0000000000000098
[ 191.367600] RBP: ff45fbe0c1c037c0 R08: 0000000000000000 R09: 0000000000000001
[ 191.368225] R10: ff45fbe0d2b01000 R11: 0000000000000008 R12: 0000000000000000
[ 191.368874] R13: 000000000000000b R14: ff43dc27509d67c0 R15: 0000000000000020
[ 191.369549] FS: 00007dbc5001e740(0000) GS:ff43dc663f380000(0000) knlGS:0000000000000000
[ 191.370213] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 191.370830] CR2: 0000000000000098 CR3: 0000000168e8e002 CR4: 0000000000b73ef0
[ 191.371557] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 191.372192] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
[ 191.372906] Call Trace:
[ 191.373262]
[ 191.373621] ? show_regs+0x64/0x70
[ 191.374040] ? __die+0x24/0x70
[ 191.374468] ? page_fault_oops+0x290/0x5b0
[ 191.374875] ? do_user_addr_fault+0x448/0x800
[ 191.375357] ? exc_page_fault+0x7a/0x160
[ 191.375971] ? asm_exc_page_fault+0x27/0x30
[ 191.376416] ? down_write+0x19/0x50
[ 191.376832] ? down_write+0x12/0x50
[ 191.377232] simple_recursive_removal+0x4a/0x2a0
[ 191.377679] ? __pfx_remove_one+0x10/0x10
[ 191.378088] debugfs_remove+0x44/0x70
[ 191.378530] mana_detach+0x17c/0x4f0
[ 191.378950] ? __flush_work+0x1e2/0x3b0
[ 191.379362] ? __cond_resched+0x1a/0x50
[ 191.379787] mana_remove+0xf2/0x1a0
[ 191.380193] mana_gd_shutdown+0x3b/0x70
[ 191.380642] pci_device_shutdown+0x3a/0x80
[ 191.381063] device_shutdown+0x13e/0x230
[ 191.381480] kernel_power_off+0x35/0x80
[ 191.381890] hibernate+0x3c6/0x470
[ 191.382312] state_store+0xcb/0xd0
[ 191.382734] kobj_attr_store+0x12/0x30
[ 191.383211] sysfs_kf_write+0x3e/0x50
[ 191.383640] kernfs_fop_write_iter+0x140/0x1d0
[ 191.384106] vfs_write+0x271/0x440
[ 191.384521] ksys_write+0x72/0xf0
[ 191.384924] __x64_sys_write+0x19/0x20
[ 191.385313] x64_sys_call+0x2b0/0x20b0
[ 191.385736] do_syscall_64+0x79/0x150
[ 191.386146] ? __mod_memcg_lruvec_state+0xe7/0x240
[ 191.386676] ? __lruvec_stat_mod_folio+0x79/0xb0
[ 191.387124] ? __pfx_lru_add+0x10/0x10
[ 191.387515] ? queued_spin_unlock+0x9/0x10
[ 191.387937] ? do_anonymous_page+0x33c/0xa00
[ 191.388374] ? __handle_mm_fault+0xcf3/0x1210
[ 191.388805] ? __count_memcg_events+0xbe/0x180
[ 191.389235] ? handle_mm_fault+0xae/0x300
[ 19
---truncated---
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 02/01/2026
The vulnerability described in CVE-2025-21953 resides within the Linux kernel's MANA network driver, specifically in how it manages debugfs structures during hibernation operations. The issue manifests when a MANA virtual machine undergoes hibernation, triggering a sequence of driver functions including mana_gd_suspend(), mana_gd_resume(), and mana_gd_shutdown(). During the resume phase, if hardware creation fails, the mana_port_debugfs pointer remains uninitialized and continues to reference a previously cleaned-up debugfs entry. This improper state management leads to a critical kernel NULL pointer dereference when mana_gd_shutdown() attempts to clean up the stale debugfs structure, causing a system crash. The root cause of this vulnerability aligns with CWE-476, which denotes a NULL pointer dereference, and can be categorized under ATT&CK technique T1490 for denial of service via resource exhaustion or system instability. The kernel's handling of device shutdown and debugfs cleanup during hibernation cycles lacks proper state validation, leading to a scenario where freed memory structures are accessed, resulting in a kernel oops and system panic.
The technical flaw occurs in the interaction between hibernation state management and debugfs cleanup mechanisms within the MANA driver. When mana_gd_resume() fails to create hardware components, it does not properly reinitialize the mana_port_debugfs pointer, leaving it in a dangling state. Subsequently, during hibernate_snapshot() and the following power_down() sequence, mana_gd_shutdown() calls debugfs_remove() on this stale pointer, which eventually leads to a NULL pointer dereference at the down_write() function. The crash occurs at memory address 0x0000000000000098, indicating that the kernel attempts to access a field within a structure that has already been freed, which is a classic symptom of improper resource cleanup in kernel space. The stack trace clearly shows the call path leading to the crash, beginning with debugfs_remove() and ending with down_write(), confirming the access to invalid memory. This flaw demonstrates a lack of proper error handling and state recovery in the driver's hibernation implementation, creating a persistent vulnerability that can be triggered through normal system hibernation operations.
The operational impact of CVE-2025-21953 extends beyond simple system crashes, potentially compromising system availability and stability in virtualized environments. When triggered during hibernation, the vulnerability causes immediate system panic, forcing a reboot and interrupting ongoing operations. In enterprise or cloud computing scenarios, where hibernation is a common power management feature, this vulnerability can lead to service disruptions, data loss, and increased maintenance overhead. The vulnerability is particularly concerning for Microsoft Hyper-V environments, as indicated by the system information in the crash dump, where the MANA driver is used for network virtualization. The issue affects systems running kernel versions including 6.14.0-rc5+, making it a significant concern for any deployment using recent Linux kernel versions with MANA network support. Organizations relying on virtualized infrastructure may experience unexpected downtime during scheduled maintenance windows or power management operations, as the system becomes unstable during hibernation cycles.
Mitigation strategies for CVE-2025-21953 should focus on implementing proper state management and resource cleanup within the MANA driver during hibernation operations. The primary fix involves ensuring that the mana_port_debugfs pointer is properly reinitialized after hibernation resume failures, preventing access to freed memory structures. Kernel patches should enforce proper error handling in mana_gd_resume() to validate hardware creation success before proceeding with debugfs initialization. Additionally, implementing defensive programming practices such as null pointer checks before debugfs operations and ensuring proper cleanup sequences during both successful and failed hibernation paths would prevent similar issues. System administrators should consider applying kernel updates as soon as patches become available, and monitor hibernation-related operations for any signs of instability. The vulnerability highlights the importance of comprehensive testing for power management features in network drivers, particularly in virtualized environments where hibernation and suspend operations are frequently used for resource optimization and energy conservation. Organizations should also consider implementing automated hibernation testing procedures to detect such issues in their deployment environments before they cause production disruptions.