CVE-2022-48914 in Linux
Summary
by MITRE • 08/22/2024
In the Linux kernel, the following vulnerability has been resolved:
xen/netfront: destroy queues before real_num_tx_queues is zeroed
xennet_destroy_queues() relies on info->netdev->real_num_tx_queues to delete queues. Since d7dac083414eb5bb99a6d2ed53dc2c1b405224e5 ("net-sysfs: update the queue counts in the unregistration path"), unregister_netdev() indirectly sets real_num_tx_queues to 0. Those two facts together means, that xennet_destroy_queues() called from xennet_remove() cannot do its job, because it's called after unregister_netdev(). This results in kfree-ing queues that are still linked in napi, which ultimately crashes:
BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 1 PID: 52 Comm: xenwatch Tainted: G W 5.16.10-1.32.fc32.qubes.x86_64+ #226 RIP: 0010:free_netdev+0xa3/0x1a0 Code: ff 48 89 df e8 2e e9 00 00 48 8b 43 50 48 8b 08 48 8d b8 a0 fe ff ff 48 8d a9 a0 fe ff ff 49 39 c4 75 26 eb 47 e8 ed c1 66 ff 8b 85 60 01 00 00 48 8d 95 60 01 00 00 48 89 ef 48 2d 60 01 00 RSP: 0000:ffffc90000bcfd00 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88800edad000 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffffc90000bcfc30 RDI: 00000000ffffffff RBP: fffffffffffffea0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: ffff88800edad050 R13: ffff8880065f8f88 R14: 0000000000000000 R15: ffff8880066c6680 FS: 0000000000000000(0000) GS:ffff8880f3300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000000e998c006 CR4: 00000000003706e0 Call Trace: xennet_remove+0x13d/0x300 [xen_netfront]
xenbus_dev_remove+0x6d/0xf0 __device_release_driver+0x17a/0x240 device_release_driver+0x24/0x30 bus_remove_device+0xd8/0x140 device_del+0x18b/0x410 ? _raw_spin_unlock+0x16/0x30 ? klist_iter_exit+0x14/0x20 ? xenbus_dev_request_and_reply+0x80/0x80 device_unregister+0x13/0x60 xenbus_dev_changed+0x18e/0x1f0 xenwatch_thread+0xc0/0x1a0 ? do_wait_intr_irq+0xa0/0xa0 kthread+0x16b/0x190 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x22/0x30
Fix this by calling xennet_destroy_queues() from xennet_uninit(), when real_num_tx_queues is still available. This ensures that queues are destroyed when real_num_tx_queues is set to 0, regardless of how unregister_netdev() was called.
Originally reported at https://github.com/QubesOS/qubes-issues/issues/7257
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/13/2024
The vulnerability described in CVE-2022-48914 represents a critical race condition within the Linux kernel's Xen network frontend driver implementation. This flaw manifests specifically in the xennet driver's queue management during device removal operations, creating a scenario where kernel memory corruption can occur due to improper resource cleanup sequencing. The vulnerability stems from the improper timing of queue destruction relative to network device unregistration, which directly violates fundamental principles of kernel memory management and device lifecycle handling.
The technical root cause of this vulnerability involves the improper ordering of operations during Xen network device removal. When a Xen network frontend device is removed, the xennet_remove() function is called which attempts to destroy network queues through xennet_destroy_queues(). However, this function relies on the netdev->real_num_tx_queues field to determine how many queues to destroy. The issue arises because since kernel commit d7dac083414eb5bb99a6d2ed53dc2c1b405224e5, the unregister_netdev() function automatically sets real_num_tx_queues to zero as part of its cleanup process. This means xennet_destroy_queues() is called after unregister_netdev() has already modified the queue count, leaving the function with invalid information about the actual number of queues that need cleanup. The subsequent attempt to free memory structures that are still linked to the NAPI (Network API) subsystem results in a kernel NULL pointer dereference, which crashes the entire system.
This vulnerability directly relates to CWE-129, which addresses improper validation of array indices, and CWE-415, which covers double free conditions. The attack surface is particularly concerning for virtualized environments where Xen hypervisor is utilized, as the flaw can be exploited to cause denial of service attacks that crash the entire kernel. The operational impact extends beyond simple system crashes to potentially compromise the stability of virtual machine environments, especially in security-sensitive deployments like Qubes OS where this vulnerability was originally reported. The crash occurs in the free_netdev function which indicates that memory corruption has already occurred, making this a particularly dangerous vulnerability that can be leveraged for system instability.
The fix implemented addresses this issue by reordering the cleanup operations within the xennet_uninit() function, ensuring that xennet_destroy_queues() is called before unregister_netdev() modifies the real_num_tx_queues field. This approach aligns with the ATT&CK framework's concept of privilege escalation through kernel exploitation by ensuring proper resource management and preventing memory corruption during device teardown. The solution requires careful consideration of kernel device lifecycle management principles and proper sequencing of operations that interact with shared kernel data structures. The mitigation strategy specifically targets the race condition by ensuring that queue destruction occurs at the appropriate time when the queue count information is still valid, preventing the kernel from attempting to free memory structures that are still referenced by the network subsystem. This fix demonstrates the importance of understanding complex kernel interaction patterns and proper resource management in virtualized environments where multiple subsystems must coordinate their cleanup operations to maintain system stability.