Cloudanix VulnDB

CVE-2026-99155

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's Xen storage driver lets a malicious backend crash guest systems by sending an invalid reply, causing sudden loss of service until the kernel is updated.

Exploitation
Other
Attacker needs
High Privilege
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Improper Input Validation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

NULL pointer dereference in scsifront_do_response when a backend response supplies an in-range rqid whose shadow slot is unpopulated, causing a crash of the Xen guest kernel.

Why it matters to the business

A compromised or malicious storage backend can trigger repeated guest crashes, resulting in denial of service and loss of availability for workloads relying on the Xen SCSI frontend.

How an attack unfolds

An attacker who controls the Xen storage backend fabricates a response ring entry whose rqid is within VSCSIIF_MAX_REQS but does not correspond to an in-flight request; the frontend indexes into the shadow array, dereferences the NULL entry, and panics the guest before any legitimate command is issued.

How to fix it

Apply the upstream kernel patch that adds a NULL check on the shadow entry before dereference; rebuild and deploy the fixed kernel to all Xen guests using the scsifront driver.

How to confirm the fix worked

Confirm the patch is present by inspecting the scsifront_do_response function for the added shadow-slot validity test; verify the guest no longer crashes when a crafted response with an unused rqid is injected.

Typical attack path

  1. Compromise or control the Xen backend domain that services the guest's SCSI frontend ring.
  2. Send a spurious or replayed response whose rqid value selects an unpopulated shadow slot.
  3. Trigger the NULL dereference in scsifront_do_response inside the guest kernel.
  4. Cause guest kernel panic and reboot or halt.

How to detect it

Search guest kernel logs and crash dumps for oops or panic messages originating from scsifront_do_response that reference NULL pointer dereference or invalid shadow entries; correlate with Xen ring activity from the backend domain.

  • scsi: xen/scsifront
  • scsifront_do_response
  • NULL pointer dereference
  • shadow entry
  • VSCSIIF_MAX_REQS

What your security team should do

  • Prioritize kernel updates for all Xen PV guests that expose SCSI frontends.
  • Monitor kernel logs for scsifront NULL dereference oops signatures.
  • Consider isolating untrusted storage backends until patches are applied.

The record

In the Linux kernel, the following vulnerability has been resolved: scsi: xen/scsifront: Check for a NULL shadow entry on a backend response scsifront_do_response() validates the rqid in a backend response against VSCSIIF_MAX_REQS before using it to index info->shadow[], but then dereferences the entry to test ->inflight without checking that the slot is populated. Shadow slots are NULL before a command is submitted (the host private area is zeroed at allocation) and are reset to NULL in _scsifront_put_rqid() once a request completes, so an in-range rqid that does not correspond to an outstanding request makes the frontend dereference a NULL pointer. A malicious or buggy backend can thus crash the guest by returning a response whose rqid is in range but not in flight -- for example a spurious response before any command has been issued, or a duplicate of one already completed. The ring has only VSCSIIF_MAX_REQS (16) slots, so before the first command every in-range rqid selects a NULL slot. Reject a response whose shadow slot is not populated.

Affected packages

Ecosystem Package Introduced Fixed