Debian Patches

Status for ironic/1:29.0.5-0+deb13u2

Patch Description Author Forwarded Bugs Origin Last update
adds-alembic.ini-in-MANIFEST.in.patch Fixes MANIFEST.in so that alembic.ini is packaged Thomas Goirand <zigo@debian.org> no 2016-03-22
fix-initial_grub_cfg.template.patch Fix initial_grub_cfg.template The default grub.cfg happen /srv/tftp, but tftp-hpa is, in Debian,
already doing a chroot in there.		 Thomas Goirand <zigo@debian.org> no 2024-09-16
do-not-print.patch Do not print Without this patch, we're getting:
.
File "/<<PKGBUILDDIR>>/ironic/tests/unit/api/base.py", line 115, in _request_json
print(method.upper(), full_path, "WITH", params, "GOT", str(response))
BlockingIOError: [Errno 11] write could not complete without blocking
.
about 60 times (not always the same number of times...).

===================================================================		 Thomas Goirand <zigo@debian.org> not-needed 2023-10-05
CVE-2026-44916_Use_sandbox_rendering_for_jinja2.patch CVE-2026-44916: security: Use sandbox rendering for jinja2 Analysis revealed that a malicious attacker with sufficent
access to request a node to be provisioned could supply a
maliciously crafted kickstart template configuration,
which would then be rendered in an unsafe form ultimately.
.
This is because the underlying render utility was modeled
for rendering only admin-suppied files or the in-code tree
files. Anaconda had to take this further by allowing the
jinja utilized to be user supplied.
.
Anyhow, an attacker with sufficient access, an ironic deployment
with the anaconda deploy interface, a node with the anaconda
deployment interface set by an admin, and a malicious template
could result in conductor internal data being rendered and if
the infrastucture operator is allowing traffic egress for the
provisioning network, could have sensitive internal data
exfiled out of the environment.
.
The render helper has been changed to utilize a sandboxed
environment. Attacks such as this now internally raise
a Jinja2 SecurityError.

diff --git a/ironic/common/utils.py b/ironic/common/utils.py
index b126668..0182173 100644		 Julia Kreger <juliaashleykreger@gmail.com> yes upstream upstream, https://review.opendev.org/c/openstack/ironic/+/987776 2026-05-08
CVE-2026-44919_move_file_url_validation_up_into_deploy_utils_main_path.patch CVE-2026-44919: move file url validation up into deploy_utils main path An issue was discovered where we were executing checksums
prior to doing file path guard logic. We've moved the check
into the same area of the code where we do all other url checks
for consistency.
.
This issue is tracked as CVE-2026-44919.
.

diff --git a/ironic/common/image_service.py b/ironic/common/image_service.py
index c68be56..209f636 100644		 Julia Kreger <juliaashleykreger@gmail.com> yes debian upstream upstream, https://review.opendev.org/c/openstack/ironic/+/988357 2026-05-16
CVE-2026-44917_disable-driver_info-level-pxe_template-override.patch CVE-2026-44917:: disable driver_info level pxe_template override 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.

diff --git a/ironic/conf/pxe.py b/ironic/conf/pxe.py
index e4c912192..e84438a47 100644		 Julia Kreger <juliaashleykreger@gmail.com> yes upstream upstream, pre-OSSA mailing list 2026-06-01
CVE-2026-46447_Sanitize-kernel_append_parms.patch CVE-2026-46447: 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.

diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index fc29f02e6..b5d616b3c 100644		 Clif Houck <me@clifhouck.com> yes upstream upstream, pre-OSSA mailing list 2026-06-01
CVE-2026-48681-directory_transversal_ISO9660_support.patch CVE-2026-48681: directory transversal ISO9660 support 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.
.

diff --git a/ironic/common/exception.py b/ironic/common/exception.py
index 3d00882b3..23b3a23a0 100644		 Julia Kreger <juliaashleykreger@gmail.com> yes upstream upstream, pre-OSSA mailing list 2026-06-01

All known versions for source package 'ironic'

Links