Raefko

**Name of the Vulnerable Software and Affected Versions** Incus versions prior to 7.0.0 **Description** Incus is a system container and virtual machine manager. An authenticated user can provide a specially crafted image or backup tarball containing a very large YAML document. Because the software unpacks these tarballs and parses YAML files without size restrictions, the document can be loaded into memory, potentially causing the server to run out of memory and degrade service. This occurs because the `getImageMetadata()` and `backup.GetInfo()` functions call the YAML decoder directly on the tar reader without limiting the bytes consumed or checking the `hdr.Size` of the tar entry. While the system mitigates alias and anchor bombs, large flat YAML documents can still cause memory consumption approximately 5x to 6x the input size. **Recommendations** Update to version 7.0.0.

**Name of the Vulnerable Software and Affected Versions** Incus versions prior to 7.0.0 **Description** An authenticated user with permissions to import instance backups can crash the Incus daemon using a specially crafted backup archive. The issue occurs because the `backup.GetInfo()` function trusts the inline `backup/index.yaml` configuration and only parses the legacy `backup/container/backup.yaml` file if the initial configuration is null. A malicious archive can contain a valid inline configuration to pass initial checks but include a malformed legacy `backup.yaml` file that omits the container section. When the archive is extracted, the `ParseConfigYamlFile()` function accepts the YAML document without a container section. Subsequently, functions such as `backup.UpdateInstanceConfig()` and `internalImportFromBackup()` attempt to dereference the `.Container` variable without checking if it is null, leading to a nil-pointer dereference and a system crash during the restore path. **Recommendations** Update to version 7.0.0.

**Name of the Vulnerable Software and Affected Versions** Incus versions prior to 7.0.0 **Description** Missing error handling in the `TransferManager.UploadAllFiles()` function allows an authenticated user to cause a daemon crash. The issue occurs during the import of a truncated or corrupted storage bucket backup archive. Specifically, the system iterates over tar entries but only checks for `io.EOF` from `tr.Next()`. If a non-EOF error occurs, such as an unexpected EOF from a truncated archive, the header `hdr` becomes nil, leading to a nil-pointer dereference when the code attempts to access `hdr.Name`, which triggers a daemon panic. **Recommendations** Update to version 7.0.0.