Affected: AlmaLinux:9: ignition

Ignition is a utility used to manipulate systems during the initramfs. This includes partitioning disks, formatting partitions, writing files (regular files, systemd units, etc.), and configuring users. On first boot, Ignition reads its configuration from a source of truth (remote URL, network metadata service, hypervisor bridge, etc.) and applies the configuration.

The following packages have been upgraded to a later upstream version: ignition (2.14.0). (BZ#2090647)

Security Fix(es):

* ignition: configs are accessible from unprivileged containers in VMs running on VMware products (CVE-2022-1706)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

Additional Changes:

For detailed information on changes in this release, see the AlmaLinux Release Notes linked from the References section.

A vulnerability was found in Ignition where ignition configs are accessible from unprivileged containers in VMs running on VMware products. This issue is only relevant in user environments where the Ignition config contains secrets. The highest threat from this vulnerability is to data confidentiality. Possible workaround is to not put secrets in the Ignition config.

Affected: Go: github.com/coreos/ignition/v2, Go: github.com/coreos/ignition

### Impact Unprivileged software in VMware VMs, including software running in unprivileged containers, can retrieve an Ignition config stored in a hypervisor guestinfo variable or OVF environment. If the Ignition config contains secrets, this can result in the compromise of sensitive information.

### Patches Ignition 2.14.0 and later [adds](https://github.com/coreos/ignition/pull/1350) a new systemd service, `ignition-delete-config.service`, that deletes the Ignition config from supported hypervisors (currently VMware and VirtualBox) during the first boot. This ensures that unprivileged software cannot retrieve the Ignition config from the hypervisor.

If you have external tooling that requires the Ignition config to remain accessible in VM metadata after provisioning, and your Ignition config does not include sensitive information, you can prevent Ignition 2.14.0 and later from deleting the config by masking `ignition-delete-config.service`. For example:

```json { "ignition": { "version": "3.0.0" }, "systemd": { "units": [ { "name": "ignition-delete-config.service", "mask": true } ] } } ```

### Workarounds [Avoid storing secrets](https://coreos.github.io/ignition/operator-notes/#secrets) in Ignition configs. In addition to VMware, many cloud platforms allow unprivileged software in a VM to retrieve the Ignition config from a networked cloud metadata service. While platform-specific mitigation is possible, such as firewal…

golang.org/x/crypto: empty plaintext packet causes panic golang: net/http: improper sanitization of Transfer-Encoding header ignition: configs are accessible from unprivileged containers in VMs running on VMware products prometheus/client_golang: Denial of service using InstrumentHandlerCounter golang: math/big: uncontrolled memory consumption due to an unhandled overflow via Rat.SetString golang: cmd/go: misinterpretation of branch names can lead to incorrect access control golang: crypto/elliptic: IsOnCurve returns true for invalid field elements golang: encoding/pem: fix stack overflow in Decode golang: regexp: stack exhaustion via a deeply nested expression golang: crash in a golang.org/x/crypto/ssh server golang: crypto/elliptic: panic caused by oversized scalar runc: incorrect handling of inheritable capabilities

ignition: configs are accessible from unprivileged containers in VMs running on VMware products

Security update for ignition

Affected: Ubuntu:Pro:22.04:LTS: ignition, Ubuntu:Pro:24.04:LTS: ignition, Ubuntu:25.10: ignition, Ubuntu:26.04:LTS: ignition

A vulnerability was found in Ignition where ignition configs are accessible from unprivileged containers in VMs running on VMware products. This issue is only relevant in user environments where the Ignition config contains secrets. The highest threat from this vulnerability is to data confidentiality. Possible workaround is to not put secrets in the Ignition config.

Ein lokaler Angreifer kann mehrere Schwachstellen in Red Hat Enterprise Linux ausnutzen, um einen Denial of Service Angriff durchzuführen, Sicherheitsvorkehrungen zu umgehen oder sonstige Auswirkungen zu verursachen.