LiveActive security incident?Get immediate response
CVE Record

CVE-2022-48914: xen/netfront: destroy queues before real_num_tx_queues is zeroed

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 <48> 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: <TASK> 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 </TASK> 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

UnknownCVSS not scoredNot KEV-listedUpdated
Discuss exposureBack to CVEs
Glexia's TakeAutomated analysismoderate

Security readout for executives and security teams

Plain-English summary

CVE-2022-48914 is a Linux kernel bug in the Xen network frontend driver. During device removal, network queues can be freed while still referenced, leading to a kernel NULL pointer crash. The most relevant business impact is availability disruption for Linux systems running as Xen guests. No source provided indicates active exploitation.

Executive priority

Handle through normal-to-expedited Linux kernel patching for Xen guest environments. Raise priority where guest outages would affect critical services. There is no cited evidence of active exploitation, but the crash condition can affect availability.

Technical view

In xen/netfront, xennet_destroy_queues() depended on real_num_tx_queues. After a net-sysfs change, unregister_netdev() can zero that value before xennet_remove() destroys queues. The fix moves queue destruction into xennet_uninit(), while queue count information is still available. The observed failure path ends in free_netdev() during xenwatch processing.

Likely exposure

Exposure appears limited to Linux kernels using the Xen netfront driver, such as Xen-based virtualized environments and Qubes-style deployments. Systems not running Xen guest networking are unlikely to be affected based on the provided sources.

Exploitation context

The source describes a crash triggered during Xen netfront device removal or unregister paths. It does not provide evidence of remote code execution, privilege escalation, public exploit activity, or CISA KEV listing. Treat this primarily as an availability risk unless vendor guidance states otherwise.

Researcher notes

The CVE record is sparse on affected ranges and severity. The useful technical detail is in the kernel fix rationale: unregister_netdev() zeroes real_num_tx_queues before xennet_destroy_queues() runs. The fix changes ordering by invoking destruction from xennet_uninit(). Avoid assuming broader Linux exposure without Xen netfront usage evidence.

Mitigation direction

  • Identify Linux systems running as Xen guests with xen_netfront networking.
  • Apply vendor kernel updates that include the referenced stable Linux fixes.
  • For custom kernels, confirm the xen/netfront queue-destruction fix is backported.
  • Prioritize Xen hosts supporting critical workloads or Qubes-like environments.
  • Follow distribution or vendor advisories for reboot and maintenance requirements.

Validation and detection

  • Inventory affected kernel versions and Xen guest usage.
  • Confirm installed kernels include the referenced stable commits or vendor backports.
  • Review kernel logs for xen_netfront, free_netdev, xenwatch, or NULL pointer crash signatures.
  • Validate after updating that Xen guest networking survives device removal or lifecycle events.
  • Track vendor advisories because the CVE record lacks CVSS and detailed affected-version ranges.
Prepared
Confidence
medium
Sources
9

Public sources used

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Potential ATT&CK relevance

Conservative CVE-to-ATT&CK context

These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.

ATT&CK lookup starting points

Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.

cve · low confidence lookup

CVE-2022-48914 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.

0CVSS vectors
3Timeline events
1ADP providers
7Source links

SSVC decision data

CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: noTechnical Impact: partial

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

ADP provider summaries

CISA-ADPCISA ADP Vulnrichment
other:ssvc

Source materials

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinux35cad2003b6447932cfe91f795090586306738e8, a5d8e6189b134f5db61be5cd59cf5a74bb01edc7, 443133330a5d4a3fd429179d460cc297724fefe8, 0abd3f9903fae6ecf8db3c89a459971fe7925499, c5eb468cbc1fa663bf0cc6c5360802dea4e611c2, d7dac083414eb5bb99a6d2ed53dc2c1b405224e5unaffected
LinuxLinux4.19.226, 5.4.174, 5.10.94, 5.15.17, 5.16.3unaffected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.