| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| Install-missed-files.patch | [PATCH] Install missed files | Ivan Udovichenko <iudovichenko@mirantis.com> | no | 2016-03-11 | ||
| clean-up-build_requests-table-on-upgrades.patch | Clean-up build_requests on upgrades | Thomas Goirand <zigo@debian.org> | no | 2016-10-19 | ||
| remove-crashing-blockdiag-doc-line.patch | Removed crashing blockdiag doc line This line is making blockdiag stack dump. Until a better fix can be found, we just remove that. =================================================================== |
Thomas Goirand <zigo@debian.org> | not-needed | 2018-02-20 | ||
| remove-svg-converter-from-doc-conf.py.patch | Remove sphinxcontrib.rsvgconverter from doc conf.py =================================================================== |
Thomas Goirand <zigo@debian.org> | not-needed | 2019-09-28 | ||
| Add-a-healtcheck-url.patch | [PATCH] Add a /healthcheck URL This is useful for operators to configure HAProxy and for monitoring. |
Thomas Goirand <zigo@debian.org> | no | 2020-04-30 | ||
| libvirt_UEFI_pc_skip_OVMF_CODE.secboot.fd_if_possible.patch | [PATCH] [stable-only] libvirt: UEFI: pc: skip OVMF_CODE.secboot.fd if possible Option `hw_firwmare_type=uefi` might create _unbootable_ servers on Ussuri and Victoria if OVMF_CODE.secboot.fd is found and has SB+SMM features (both are usually true), because SMM requires `q35`, thus fails to boot on `pc`. . So, check for non-`q35` machine type and try another file. If there's none, log that. (We know it might fail to boot. Maybe it should error out? but this is stable-only..) . Add unit tests for the 6 possible scenarios (`pc/q35` with both files present and either file present). . Why stable-only and not cherry-picks? . Wallaby and later are fixed with refactoring, as part of the Secure Boot implementation, but that's big/risky; see commit 9fff6893ce2e ("libvirt: Use firmware metadata files to configure instance"). . That removed the hardcoded paths from commit 363710b65543 ("libvirt: Handle alternative UEFI firmware binary paths"). . Docs: . [0] https://docs.openstack.org/nova/wallaby/admin/uefi.html [1] https://docs.openstack.org/nova/wallaby/admin/secure-boot.html [2] https://docs.openstack.org/nova/wallaby/user/flavors.html [3] https://specs.openstack.org/openstack/nova-specs/specs/wallaby/implemented/allow-secure-boot-for-qemu-kvm-guests.html . Test: . $ openstack image set --property hw_firmware_type=uefi bionic $ openstack server create --image bionic --flavor m1.small --network private srv . Before: . $ virsh dumpxml $guest; done | grep -e nova:name -e machine= -e loader' <nova:name>srv</nova:name> <type arch='x86_64' machine='pc-i440fx-4.2'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.secboot.fd</loader> . Guest doesn't boot; nothing in the console log: . $ openstack console log show srv | grep -i -e efi -e bios $ . After: . $ virsh dumpxml $guest; done | grep -e nova:name -e machine= -e loader' <nova:name>srv</nova:name> <type arch='x86_64' machine='pc-i440fx-4.2'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fd</loader> . Guest booted; details in the console log: . $ openstack console log show srv | grep -i -e efi -e bios ... Creating boot entry "Boot0003" with label "ubuntu" for file "\EFI\ubuntu\shimx64.efi" ... [ 0.000000] efi: EFI v2.70 by EDK II [ 0.000000] efi: SMBIOS=0x7fbcd000 ACPI=0x7fbfa000 ACPI 2.0=0x7fbfa014 MEMATTR=0x7eb30018 [ 0.000000] SMBIOS 2.8 present. [ 0.000000] DMI: OpenStack Foundation OpenStack Nova, BIOS 0.0.0 02/06/2015 ... . Note that the XML snippet for the loader is aligned with Wallaby, in which just setting hw_firmware_type=uefi works out of the box: . $ juju run --app nova-compute 'for guest in $(virsh list --name); do \ virsh dumpxml $guest; done | grep -e nova:name -e machine= -e loader' <nova:name>srv</nova:name> <type arch='x86_64' machine='pc-i440fx-4.2'>hvm</type> <loader readonly='yes' secure='no' type='pflash'>/usr/share/OVMF/OVMF_CODE.fd</loader> . =================================================================== |
Mauricio Faria de Oliveira <mfo@canonical.com> | no | upstream, https://review.opendev.org/c/openstack/nova/+/828979 | 2022-06-10 | |
| cve-2022-47951-nova-stable-victoria.patch | CVE-2022-47951: Check VMDK create-type against an allowed list diff --git a/nova/conf/compute.py b/nova/conf/compute.py index 5cf8c31714..319d6571d1 100644 |
Dan Smith <dansmith@redhat.com> | no | debian | 2022-01-24 | |
| Handle_no_RAM_info_was_set_migration_case.patch | Handle "no RAM info was set" migration case This handles the case where the live migration monitoring thread may race and call jobStats() after the migration has completed resulting in the following error: . libvirt.libvirtError: internal error: migration was active, but no RAM info was set . (cherry picked from commit 9fea934c71d3c2fa7fdd80c67d94e18466c5cf9a) (cherry picked from commit 00396fa9396324780c09161ed57a86b7e458c26f) (cherry picked from commit 4316234e63b76e4f9877ec6e924b5c54ea761bbb) (cherry picked from commit 98d9936e54b900db1bd2d5477a9a1d7e5a7be104) (cherry picked from commit 6d68aee626875a165667e04c4ccc54ff3073e4ff) diff --git a/nova/tests/unit/virt/libvirt/test_guest.py b/nova/tests/unit/virt/libvirt/test_guest.py index 3cab237..9884e5c 100644 |
Brett Milford <brett.milford@canonical.com> | no | upstream, https://review.opendev.org/c/openstack/nova/+/860736 | 2023-03-06 | |
| libvirt_Allow_disabling_CPU_flags_via_cpu_model_extra_flags.patch | libvirt: Allow disabling CPU flags via `cpu_model_extra_flags` Parse a comma-separated list of CPU flags from `[libvirt]/cpu_model_extra_flags`. If the CPU flag starts with '+', enable the feature in Nova guest CPU guest XML, or if it starts with '-', disable the feature. If neither '+' nor '-' is specified, enable the flag. For example, on a compute node that is running hardware (e.g. an Intel server that supports TSX) and virtualization software that supports the given CPU flags, if a user provides this config: . [libvirt] cpu_mode = custom cpu_models = Cascadelake-Server cpu_model_extra_flags = -hle, -rtm, +ssbd, mtrr . Then Nova should generate this CPU for the guest: . <cpu match='exact'> <model fallback='forbid'>Cascadelake-Server</model> <vendor>Intel</vendor> <feature policy='require' name='ssbd'/> <feature policy='require' name='mtrr'/> <feature policy='disable' name='hle'/> <feature policy='disable' name='rtm'/> </cpu> . This ability to selectively disable CPU flags lets you avoid any CPU flags that need to be disabled for any number of reasons. E.g. disable a CPU flag that is a potential security risk, or disable one that causes a performance penalty. =================================================================== |
Kashyap Chamarthy <kchamart@redhat.com> | no | upstream, https://review.opendev.org/c/openstack/nova/+/774240 | 2023-06-30 | |
| CVE-2024-32498_1_libvirt-Create-qcow2-disks-with-the-correct-size-without-extending.patch | [PATCH] libvirt: Create qcow2 disks with the correct size without extending All callers to the create_image method of the Qcow2 imagebackend provide a size and so we should just always create the initial image using that size. The name of the method is also misleading and changed to better reflect that an image is being created here and not copied. =================================================================== |
Lee Yarwood <lyarwood@redhat.com> | yes | debian upstream | upstream, https://review.opendev.org/c/openstack/nova/+/779275 | 2024-07-02 |
| CVE-2024-32498_2_libvirt_Consolidate-create_cow_image-and-create_image.patch | [PATCH] libvirt: Consolidate create_cow_image and create_image This commonizes the code in create_cow_image and create_image so that creating a qcow2 image will use the same code path as any other disk format. . This is done ahead of adding encryption support to the qemu-img create command to avoid duplication. =================================================================== |
Lee Yarwood <lyarwood@redhat.com> | yes | debian upstream | upstream, https://review.opendev.org/c/openstack/nova/+/846246 | 2024-07-02 |
| CVE-2024-32498_3_libvirt_Add_encryption_support_to_qemu-img_create_command.patch | [PATCH] libvirt: Add encryption support to qemu-img create command This adds handling of options needed for qemu-img create to generate encrypted images. Related to blueprint ephemeral-storage-encryption =================================================================== |
Lee Yarwood <lyarwood@redhat.com> | yes | debian upstream | upstream, https://review.opendev.org/c/openstack/nova/+/826752 | 2024-07-02 |
| CVE-2024-32498_4_nova-stable-2023.1_Reject_qcow_files_with_data-file_attributes.patch | [PATCH 1/3] Reject qcow files with data-file attributes =================================================================== |
Dan Smith <dansmith@redhat.com> | yes | debian upstream | upstream, https://review.opendev.org/c/openstack/nova/+/923273 | 2024-06-30 |
| CVE-2024-32498_5_nova-stable-2023.1_Check_images_with_format_inspector_for_safety_2.patch | [PATCH] Check images with format_inspector for safety It has been asserted that we should not be calling qemu-img info on untrusted files. That means we need to know if they have a backing_file, data_file or other unsafe configuration *before* we use qemu-img to probe or convert them. This grafts glance's format_inspector module into nova/images so we can use it to check the file early for safety. The expectation is that this will be moved to oslo.utils (or something) later and thus we will just delete the file from nova and change our import when that happens. format_inspector.py because of autopep8 demands. (cherry picked from commit 9cdce715945619fc851ab3f43c97fab4bae4e35a) (cherry picked from commit f07fa55fd86726eeafcd4c0c687bc49dd4df9f4c) (cherry picked from commit 0acf5ee7b5dfb6ff0f9a9745f5ad2a0ed2bf65bf) |
Dan Smith <dansmith@redhat.com> | no | 2024-04-17 | ||
| CVE-2024-32498_6_nova-stable-2023.1_Additional-qemu-safety-checking-on-base-images_2.patch | [PATCH] Additional qemu safety checking on base images There is an additional way we can be fooled into using a qcow2 file with a data-file, which is uploading it as raw to glance and then booting an instance from it. Because when we go to create the ephemeral disk from a cached base image, we've lost the information about the original source's format, we probe the image's file type without a strict format specified. If a qcow2 file is listed in glance as a raw, we won't notice it until it is too late. This brings over another piece of code (proposed against) glance's format inspector which provides a safe format detection routine. This patch uses that to detect the format of and run a safety check on the base image each time we go to use it to create an ephemeral disk image from it. This also detects QED files and always marks them as unsafe as we do not support that format at all. Since we could be fooled into downloading one and passing it to qemu-img if we don't recognize it, we need to detect and reject it as unsafe. (cherry picked from commit b1b88bf001757546fbbea959f4b73cb344407dfb) (cherry picked from commit 8a0d5f2afaf40c4554419a0b2488ce092eda7a1a) (cherry picked from commit 0269234dc42fe2c320dc4696123cf5132642f9b7) |
Dan Smith <dansmith@redhat.com> | no | 2024-06-24 | ||
| CVE-2024-32498_7_Fix-vmdk_allowed_types-checking_2.patch | [PATCH] Fix vmdk_allowed_types checking This restores the vmdk_allowed_types checking in create_image() that was unintentionally lost by tightening the qemu-type-matches-glance code in the fetch patch recently. Since we are still detecting the format of base images without metadata, we would have treated a vmdk file that claims to be raw as raw in fetch, but then read it like a vmdk once it was used as a base image for something else. (cherry picked from commit 08be7b2a0dc1d7728d8034bc2aab0428c4fb642e) (cherry picked from commit 11301e7e3f0d81a3368632f90608e30d9c647111) (cherry picked from commit 70a435fd519a0ebcc3ac9ad5254fefbf19c93e48) |
Dan Smith <dansmith@redhat.com> | no | 2024-07-01 | ||
| CVE-2024-40767_1_port_format_inspector_tests_from_glance_antelope.patch | CVE-2024-40767: port format inspector tests from glance This commit is a direct port of the format inspector unit tests from glance as of commit 0d8e79b713bc31a78f0f4eac14ee594ca8520999 . the only changes to the test are as follows . "from glance.common import format_inspector" was updated to "from nova.image import format_inspector" . "from glance.tests import utils as test_utils" was replaced with "from nova import test" . "test_utils.BaseTestCase" was replaced with "test.NoDBTestCase" . "glance-unittest-formatinspector-" was replaced with "nova-unittest-formatinspector-" . This makes the test funtional in nova. . TestFormatInspectors requries qemu-img to be installed on the host which would be a new depency for executing unit tests. to avoid that we skip TestFormatInspectors if qemu-img is not installed. TestFormatInspectorInfra and TestFormatInspectorsTargeted do not have a qemu-img dependency so no changes to the test assertions were required. diff --git a/nova/tests/unit/image/test_format_inspector.py b/nova/tests/unit/image/test_format_inspector.py new file mode 100644 index 0000000..4bda796 |
Sean Mooney <work@seanmooney.info> | no | debian | upstream, https://review.opendev.org/c/openstack/nova/+/923731 | 2024-07-10 |
| CVE-2024-40767_2_Reproduce_iso_regression_with_deep_format_inspection_antelope.patch | CVE-2024-40767: Reproduce iso regression with deep format inspection This change adds a reproducer for the regression in iso file support when workarounds.disable_deep_image_inspection = False diff --git a/nova/tests/unit/image/test_format_inspector.py b/nova/tests/unit/image/test_format_inspector.py index 4bda796..9bd99c0 100644 |
Sean Mooney <work@seanmooney.info> | no | debian | upstream, https://review.opendev.org/c/openstack/nova/+/923732 | 2024-07-10 |
| CVE-2024-40767_3_Add-iso-file-format-inspector_antelope.patch | CVE-2024-40767: Add iso file format inspector This change includes unit tests for the ISO format inspector using mkisofs to generate the iso files. . A test for stashing qcow content in the system_area of an iso file is also included. . This change modifies format_inspector.detect_file_format to evaluate all inspectors until they are complete and raise an InvalidDiskInfo exception if multiple formats match. =================================================================== |
Sean Mooney <work@seanmooney.info> | yes | debian upstream | upstream, https://review.opendev.org/c/openstack/nova/+/923733 | 2024-07-10 |
| CVE-2024-40767_4_Change-force_format-strategy-to-catch-mismatches_antelope.patch | CVE-2024-40767: Change force_format strategy to catch mismatches When we moved the qemu-img command in fetch_to_raw() to force the format to what we expect, we lost the ability to identify and react to situations where qemu-img detected a file as a format that is not supported by us (i.e. identfied and safety-checked by format_inspector). In the case of some of the other VMDK variants that we don't support, we need to be sure to catch any case where qemu-img thinks it's something other than raw when we think it is, which will be the case for those formats we don't support. . Note this also moves us from explicitly using the format_inspector that we're told by glance is appropriate, to using our own detection. We assert that we agree with glance and as above, qemu agrees with us. This helps us avoid cases where the uploader lies about the image format, causing us to not run the appropriate safety check. AMI formats are a liability here since we have a very hard time asserting what they are and what they will be detected as later in the pipeline, so there is still special-casing for those. =================================================================== |
Dan Smith <dansmith@redhat.com> | yes | debian upstream | upstream, https://bugs.launchpad.net/nova/+bug/2071734 | 2024-07-10 |