Skip to content

Synchronise 2025.1 with upstream#13

Open
github-actions[bot] wants to merge 4 commits into
stackhpc/2025.1from
upstream/2025.1-2026-06-04
Open

Synchronise 2025.1 with upstream#13
github-actions[bot] wants to merge 4 commits into
stackhpc/2025.1from
upstream/2025.1-2026-06-04

Conversation

@github-actions
Copy link
Copy Markdown

@github-actions github-actions Bot commented Jun 4, 2026

This PR contains a snapshot of 2025.1 from upstream stable/2025.1.

ClifHouck and others added 3 commits June 3, 2026 13:39
By defining a kernel command line grammar and attemping to parse
kernel_append_params. A successful parse indicates the input contained
in kernel_append_params are valid kernel parameters. Unsuccessful
parsing will raise and be rejected.

This parsing can be disabled through a new conductor configuration
option: disable_kernel_parameter_parsing which is False by default.

Basic kernel parameter sanitization (ie filtering newlines) is always
applied in kernel_append_params since they are never valid for
inclusion.

Future patches should extend kernel parameter parsing to all areas of
Ironic's code base in order to guarantee valid kernel parameters being
passed along.

NOTE: This patch is back-ported from stable/2026.{1,2} and slightly
weakens the kernel command line grammar by not including init arguments.
Lark's stand-alone LALR(1) parser can't handle the ambiguity introduced.

This commit addresses CVE-2026-46447.

Closes-Bug: 2150624
Change-Id: I31ee960f6f055e39dd248f54ac853e21838632df
Signed-off-by: Clif Houck <me@clifhouck.com>
A vulnerability was identified in Ironic's handling of
ISO images where Ironic contains support to patch ISO9660
virtual media contents to include key data items like
configuration drive data and other required metadata.

Anyhow, the issue here was the Ironic service was trusting
that the submitted contents were valid, and a directory
transversal attempt could be embedded within a modified
configuration drive ISO contents submitted to Ironic.
This is a case where an attacker would take a path in an ISO,
and attempt to directly modify it to reach another path on the
filesystem which was within the confines and path structure they
were working with. i.e. while "../foo" is not a valid file or
directory name in ISO9660, it can still be represented, injected,
and read by the pycdlib library.

The code on all paths which perform this type of ISO content
interaction have been patched to explicitly check the path for
transversal attempts and internally raises an InvalidContent
exception.

Impacted features:
* Virtual Media ISO patching code path for pre-generated
  deployment ISOs as opposed to Ironic generated ISOs from
  a kernel/ramdisk.
* Anaconda deployment interfacce where a user could
  impact the resulting pathing on the node being deployed
  at deploy time.

Related-Bug: 2148333
Change-Id: I09ba308dc5088260594a502d43413d2069616703
Signed-off-by: Julia Kreger <juliaashleykreger@gmail.com>
A vulnerability report was filed pointing out a flaw in the pxe_template
override logic where a direct file path was supplied. The original usage
context of this minimally documented feature was that an operator, i.e.
the owner of the ironic deployment could leverage a direct file path to
a template on disk. This should instead have utilized the file:/// URL
provider, but research suggests this feature has largely not been used.

As a result, consensus has been reached amongst security maintainers
for the Ironic project to disable and remove this functionality.

Where this issue became a vulnerability for Ironic was the evolution
of the usage and Role Based Access Control model where we began to
separate the overall operator of the system from the administrative
manager of the system.

The resulting vector was that an authenticated and authorized user
could potentially request a template a sensitive file to be sourced
as the PXE template. This file would then be written to disk and
utilized IF the ironic-conductor service could access it. The
malicious authenticated and authorized user could then, if the
environment was misconfigured, or operating with "flat" networking,
it could be possible to guess the underlying file path on the
tftpboot/httpboot network bootendpoints, and retrieve the rendered
output before the deployment failed and the rendered output is removed.

This is tracked as CVE-2026-44917, and the underlying feature is
expected to be removed during the 2027.2.

Closes-Bug: 2148319
Change-Id: I52daa344b4d417eee09c28b53703fea792e4367b
Signed-off-by: Julia Kreger <juliaashleykreger@gmail.com>
@github-actions github-actions Bot requested a review from a team as a code owner June 4, 2026 12:56
@github-actions github-actions Bot added automated Automated action performed by GitHub Actions synchronisation labels Jun 4, 2026
…025.1-2026-06-04

Signed-off-by: Jack Hodgkiss <jack@stackhpc.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

automated Automated action performed by GitHub Actions synchronisation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants