CVE-2025-38036

What it actually does

Null pointer dereference in xe_mmio_read/write during early VF GuC communication because gt->mmio is not yet initialized.

Why it matters to the business

Kernel crashes in SR-IOV virtual function deployments on Intel Xe graphics, causing downtime for virtualized graphics workloads.

How an attack unfolds

An attacker enables SR-IOV VF mode on an affected kernel; the VF initialization path calls GuC functions that assume MMIO is ready, triggering a page fault before the early xe_gt_mmio_init fix is applied.

How to fix it

Update the Linux kernel to a version containing commit ef6e950aea76a5009ccc79ebfa955ecc66cd85a2 which performs early xe_gt_mmio_init before GuC communication in VF paths.

How to confirm the fix worked

Confirm the presence of the early xe_gt_mmio_init call in the VF initialization sequence and test that VF mode no longer produces the page fault on GuC MMIO access.

Typical attack path

1. Configure SR-IOV VF for Xe GT
2. Load xe driver in VF mode
3. Trigger GMDID fetch via GuC H2G MMIO before gt->mmio setup
4. Access unset MMIO register causing page fault crash

How to detect it

Search kernel logs for xe driver messages indicating SR-IOV VF mode followed by H2G MMIO attempts and page fault oops referencing unset MMIO addresses.

• xe 0000:00:02.1: [drm] Running in SR-IOV VF mode
• GT0: sending H2G MMIO 0x5507
• BUG: unable to handle page fault for address: 0000000000190240

What your security team should do

• Prioritize kernel upgrade to the fixed commit on systems using Xe SR-IOV
• Reboot affected hosts after patching to apply the corrected initialization order
• Review virtualization configurations to limit unnecessary VF exposure until patched