CVE-2022-48914

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xen/netfront: destroy queues before real_num_tx_queues is zeroed<br /> <br /> xennet_destroy_queues() relies on info-&gt;netdev-&gt;real_num_tx_queues to<br /> delete queues. Since d7dac083414eb5bb99a6d2ed53dc2c1b405224e5<br /> ("net-sysfs: update the queue counts in the unregistration path"),<br /> unregister_netdev() indirectly sets real_num_tx_queues to 0. Those two<br /> facts together means, that xennet_destroy_queues() called from<br /> xennet_remove() cannot do its job, because it&amp;#39;s called after<br /> unregister_netdev(). This results in kfree-ing queues that are still<br /> linked in napi, which ultimately crashes:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 1 PID: 52 Comm: xenwatch Tainted: G W 5.16.10-1.32.fc32.qubes.x86_64+ #226<br /> RIP: 0010:free_netdev+0xa3/0x1a0<br /> 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<br /> RSP: 0000:ffffc90000bcfd00 EFLAGS: 00010286<br /> RAX: 0000000000000000 RBX: ffff88800edad000 RCX: 0000000000000000<br /> RDX: 0000000000000001 RSI: ffffc90000bcfc30 RDI: 00000000ffffffff<br /> RBP: fffffffffffffea0 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000001 R12: ffff88800edad050<br /> R13: ffff8880065f8f88 R14: 0000000000000000 R15: ffff8880066c6680<br /> FS: 0000000000000000(0000) GS:ffff8880f3300000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 00000000e998c006 CR4: 00000000003706e0<br /> Call Trace:<br /> <br /> xennet_remove+0x13d/0x300 [xen_netfront]<br /> xenbus_dev_remove+0x6d/0xf0<br /> __device_release_driver+0x17a/0x240<br /> device_release_driver+0x24/0x30<br /> bus_remove_device+0xd8/0x140<br /> device_del+0x18b/0x410<br /> ? _raw_spin_unlock+0x16/0x30<br /> ? klist_iter_exit+0x14/0x20<br /> ? xenbus_dev_request_and_reply+0x80/0x80<br /> device_unregister+0x13/0x60<br /> xenbus_dev_changed+0x18e/0x1f0<br /> xenwatch_thread+0xc0/0x1a0<br /> ? do_wait_intr_irq+0xa0/0xa0<br /> kthread+0x16b/0x190<br /> ? set_kthread_struct+0x40/0x40<br /> ret_from_fork+0x22/0x30<br /> <br /> <br /> Fix this by calling xennet_destroy_queues() from xennet_uninit(),<br /> when real_num_tx_queues is still available. This ensures that queues are<br /> destroyed when real_num_tx_queues is set to 0, regardless of how<br /> unregister_netdev() was called.<br /> <br /> Originally reported at<br /> https://github.com/QubesOS/qubes-issues/issues/7257