{"uuid": "e854b969-eb36-489f-815e-df5d8ffebc88", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "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"}