https://vulnerability.circl.lu/sightings/feed 2026-05-05T10:33:19.039807+00:00 Vulnerability-Lookup info@circl.lu python-feedgen Contains only the most 10 recent sightings. https://vulnerability.circl.lu/sighting/e854b969-eb36-489f-815e-df5d8ffebc88/export 2026-05-05T10:33:19.484697+00:00 Automation user http://vulnerability.circl.lu/user/automation {"uuid": "e854b969-eb36-489f-815e-df5d8ffebc88", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2022-48914", "type": "seen", "source": "https://t.me/cvedetector/3861", "content": "{\n \"Source\": \"CVE FEED\",\n \"Title\": \"CVE-2022-48914 - Xen Netfront NULL Pointer Dereference\", \n \"Content\": \"CVE ID : CVE-2022-48914 \nPublished : Aug. 22, 2024, 2:15 a.m. | 37\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \nxen/netfront: destroy queues before real_num_tx_queues is zeroed \n \nxennet_destroy_queues() relies on info->netdev->real_num_tx_queues to \ndelete queues. Since d7dac083414eb5bb99a6d2ed53dc2c1b405224e5 \n(\"net-sysfs: update the queue counts in the unregistration path\"), \nunregister_netdev() indirectly sets real_num_tx_queues to 0. Those two \nfacts together means, that xennet_destroy_queues() called from \nxennet_remove() cannot do its job, because it's called after \nunregister_netdev(). This results in kfree-ing queues that are still \nlinked in napi, which ultimately crashes: \n \n BUG: kernel NULL pointer dereference, address: 0000000000000000 \n #PF: supervisor read access in kernel mode \n #PF: error_code(0x0000) - not-present page \n PGD 0 P4D 0 \n Oops: 0000 [#1] PREEMPT SMP PTI \n CPU: 1 PID: 52 Comm: xenwatch Tainted: G W 5.16.10-1.32.fc32.qubes.x86_64+ #226 \n RIP: 0010:free_netdev+0xa3/0x1a0 \n 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 \n RSP: 0000:ffffc90000bcfd00 EFLAGS: 00010286 \n RAX: 0000000000000000 RBX: ffff88800edad000 RCX: 0000000000000000 \n RDX: 0000000000000001 RSI: ffffc90000bcfc30 RDI: 00000000ffffffff \n RBP: fffffffffffffea0 R08: 0000000000000000 R09: 0000000000000000 \n R10: 0000000000000000 R11: 0000000000000001 R12: ffff88800edad050 \n R13: ffff8880065f8f88 R14: 0000000000000000 R15: ffff8880066c6680 \n FS: 0000000000000000(0000) GS:ffff8880f3300000(0000) knlGS:0000000000000000 \n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 \n CR2: 0000000000000000 CR3: 00000000e998c006 CR4: 00000000003706e0 \n Call Trace: \n \n xennet_remove+0x13d/0x300 [xen_netfront] \n xenbus_dev_remove+0x6d/0xf0 \n __device_release_driver+0x17a/0x240 \n device_release_driver+0x24/0x30 \n bus_remove_device+0xd8/0x140 \n device_del+0x18b/0x410 \n ? _raw_spin_unlock+0x16/0x30 \n ? klist_iter_exit+0x14/0x20 \n ? xenbus_dev_request_and_reply+0x80/0x80 \n device_unregister+0x13/0x60 \n xenbus_dev_changed+0x18e/0x1f0 \n xenwatch_thread+0xc0/0x1a0 \n ? do_wait_intr_irq+0xa0/0xa0 \n kthread+0x16b/0x190 \n ? set_kthread_struct+0x40/0x40 \n ret_from_fork+0x22/0x30 \n \n \nFix this by calling xennet_destroy_queues() from xennet_uninit(), \nwhen real_num_tx_queues is still available. This ensures that queues are \ndestroyed when real_num_tx_queues is set to 0, regardless of how \nunregister_netdev() was called. \n \nOriginally reported at \n \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n \"Detection Date\": \"22 Aug 2024\",\n \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-22T05:08:03.000000Z"} 2024-08-22T05:08:03+00:00