2025.1 Series Release Notes¶

10.2.3-2¶

During bootc deployment, the container registry pull secret was written to a well-known path on the host and passed to podman run via --authfile. Because the container runs with --privileged --pid=host, tenant-controlled code in the bootc image could read the credential through /proc/1/root/<authfile-path>. When the pull secret originates from an operator or admin source (driver_info.image_pull_secret, [deploy] image_server_user/password, or [oci] authentication_config) rather than the tenant’s own instance_info.image_pull_secret, this constitutes a cross-boundary credential disclosure to tenant-controlled bootc image code. The image pull is now performed in a separate podman pull step and the auth file is deleted before the tenant container executes. The subsequent podman run uses --pull=never so that no registry credentials are required or present at container runtime. Addresses CVE-2026-54422.

Fixes a shell command injection vulnerability in the NTP clock synchronization when using chrony. The ntp_server configuration value was interpolated into a shell command string, allowing a crafted value to execute arbitrary system commands. The chrony execution path no longer uses a shell, and the ntp_server value is now validated and sanitized before use. See bug 2160050 for details.

Disable installation of bootloaders (via grub-install) by default in order to improve security posture by adding a new configuration option enable_bios_bootloader_install which defaults to False. Operators who still need this functionality can re-enable installation of bootloaders by setting enable_bios_bootloader_install to True. Addresses CVE-2026-43003.

The GET /v1/commands and GET /v1/commands/<uuid> API endpoints now always validate the agent_token, matching the POST endpoint. Previously, these GET endpoints only started enforcing the token once a GET request happened to supply one, so if that never occurred, e.g. in typical POST/heartbeat-driven deployments, the endpoints could remain unauthenticated indefinitely. See bug 2160196 for details.

Fixes matching hints with lists of WWN/Serial which was only handled in some cases - due to the issue, it was possible to choose a device listed in the skip_block_devices property as a root device.

Fixes an issue where the agent could not find a valid IP address when the Ironic API was running on a non-standard port. The reachability test now uses the full API URL including the port number, instead of only using the hostname. This prevents LookupAgentIPError when connecting to Ironic APIs on custom ports.

Fixes RuntimeError when entering rescue mode by checking if the heartbeater thread is alive before attempting to stop it.

The agent now tests Ironic API URL reachability via HTTP during startup before determining the advertised IP address. Unreachable API URLs are filtered out, preventing the agent from advertising an IP address that cannot actually reach the Ironic API. This improves reliability when multiple API URLs are configured or in complex network topologies. The IP reachability test uses the configured http_request_timeout (default 30 seconds) timeout for the HTTP request.

Software RAID creation now correctly handles configurations where logical disks use different sets of physical devices. Previously, partition indices were incorrectly shared across all devices, causing failures when creating multiple RAID arrays on different disks.

Fixes IPA collecting the effective MAC address of NICs instead of the pesistent MAC address. In case it fails to fetch the persistent address falls back to effective MAC address. See https://bugs.launchpad.net/ironic-python-agent/+bug/2103450 for details.

Adds support to Ironic-Python-Agent to facilitate deployment of bootable containers. This is an experimental feature for standalone users. Operators wishing to disable this feature, can leverage the [DEFAULT]disable_bootc_deploy option in ironic-python-agent.conf.

Fixes a potential security issue where a third party may be able to retrieve potentially sensitive data in command result output from the agent. If a request comes in with an agent_token to the command results endpoint, the agent will now require all future calls to leverage the token to retrieve results and validate that token’s validity. This effectively eliminates the possibility of a malicious entity with access to the agent’s API endpoint from capturing the command results from agent operations.

Prevents IPA from restarting on tenant networks during rescue operations by adding proper lockdown.