Act nowDisclosed

Advisory · CVE-2026-115372

Incus restricted projects can still inject mkfs arguments through block.create_options on volume update, copy and move

Incus 7.3.0 before 7.5.0 rejects block.create_options only on direct volume creation, so a restricted project user can set it through volume update, copy or move and have it appended to the mkfs command line run as root when a pool formats the new volume. CVSS 3.1 8.5, CVSS 4.0 9.0.

Vendor
Linux Containers
Product
Incus
Identifier / CWE
CVE-2026-115372
CWE-88
Action timing
Immediate
ELI5

Explain it like I’m five

A dangerous setting was banned at the front desk, but the same setting could still be slipped in by editing an existing volume or copying one, and when the system later builds the disk it pastes that setting into a root command.

SIMPLIFIED_ATTACK_PATH04 STEPS
  1. 01Restricted user sets the option

    A user confined to a restricted project who can create or edit custom volumes sets block.create_options on an existing volume, a path the earlier fix did not reject.

  2. 02Volume is copied or moved

    The user copies or moves the volume onto a pool that formats the new volume; the copy and move paths inherit the source volume config without re-checking the target project restrictions, per the Incus advisory.

  3. 03Option reaches the format command

    The value is appended to the mkfs command line for the new volume.

  4. 04Command runs as root

    On pools that format on copy, such as non-thin LVM, mkfs executes as root with the injected arguments.

What happened

The Incus project disclosed CVE-2026-115372 in its GitHub security advisory: the fix for an earlier issue only rejected block.create_options on the direct custom volume creation path. The same value could still reach a restricted project by setting it on an existing volume, or by copying or moving a volume whose config carries it, because those paths inherit the source volume config without re-checking the target project restrictions. The CVE record lists Incus 7.3.0 before 7.5.0 as affected, with 7.5.0 as the fixed release. The CVSS 3.1 score is 8.5, with changed scope, and the CVSS 4.0 score is 9.0.

Per the advisory, a user confined to a restricted project who can create or edit custom volumes can set block.create_options on a volume, then trigger a copy or move onto a pool that formats the new volume; the value is appended to the mkfs command line executed as root, giving the same argument injection as the original issue. Only pools that format on copy, such as non-thin LVM, reach the mkfs call; on other drivers the forbidden option still lands on the volume. Per the advisory, workarounds are to not grant custom volume creation to restricted projects on pools that format on copy, or to set the pool-level volume.block.create_options so the pool default applies.

What to do

  1. Inventory Incus hosts running 7.3.0 before 7.5.0, and identify restricted projects whose members can create or edit custom volumes.
  2. Upgrade affected installations to Incus 7.5.0 or later, using the Incus project release guidance.
  3. Until upgraded, apply the advisory workarounds: do not grant custom volume creation to restricted projects on pools that format on copy, or set the pool-level default so the pool value applies.
  4. Search existing custom volumes in restricted projects for a block.create_options value, and review recent volume updates, copies and moves onto formatting pools such as non-thin LVM.
  5. Verify the deployed version on every host after updating, and re-check that restricted projects cannot set the option through any path.

Management note

This is an incomplete-fix pattern: the dangerous option was blocked on one path and left open on three others. Restricted projects are a tenant isolation promise, so audit the volumes that already carry the option, not just the version number.