CVE-2022-48969

What it actually does

NULL pointer dereference in xennet_poll during NAPI polling of a destroyed network sring after live migration when busy_poll/busy_read remains enabled, triggered because NAPIs for old srings are not removed before the srings are set to NULL.

Why it matters to the business

Kernel crashes on Xen-based Linux systems during or immediately after live migration of VMs that have busy polling enabled, leading to service disruption and potential loss of availability for virtualized workloads.

How an attack unfolds

An attacker with the ability to initiate or influence live migration of a Xen VM (or who can trigger migration in a multi-tenant environment) waits for the tiny window after srings are NULLed but before NAPIs are disabled; with busy_poll active the NAPI thread can then dereference the NULL sring on resume, causing the oops.

How to fix it

Apply the upstream fix that removes NAPIs for old srings before live migration (commit ca72f75eebe41ea7726624d8aea7da6c425f1eb9) and rebuild the kernel or update to a distribution release containing that change; disable busy_poll/busy_read as a temporary mitigation if patching is delayed.

How to confirm the fix worked

Confirm the patch is present by checking for the NAPI removal logic before sring NULLing in xen-netfront.c; test by performing live migration on a VM with busy_poll enabled and verifying no NULL dereference occurs; scan kernel sources or package versions for the fixed commit hash.

Typical attack path

1. Obtain control or influence over a Xen VM or the migration orchestrator
2. Enable or ensure busy_poll/busy_read is active on the guest network stack
3. Trigger or wait for live migration to the target host
4. Allow the guest to resume while the NAPI for the old sring is still registered
5. Force a poll that reaches xennet_poll before the NAPI is torn down

How to detect it

Search kernel logs and vmcore dumps for the signature "BUG: unable to handle kernel NULL pointer dereference" followed by "xennet_poll" and the RIP address; correlate with live migration events in Xen toolstack logs; review dmesg or journalctl for the call trace involving napi_busy_loop and xennet_alloc_rx_buffers around migration timestamps.

What your security team should do

• Prioritize patching all Xen Dom0 and guest kernels that use xen-netfront within the next maintenance window
• Temporarily disable busy_poll and busy_read sysctls on affected systems until patched
• Monitor for kernel oops containing xennet_poll and NULL pointer dereference at 0000000000000008
• Review Xen migration tooling and orchestration to reduce unnecessary live migrations