Bug#1108403: cloud-init: CVE-2024-6174
On Mon, Jul 07, 2025 at 06:00:15PM +, Jeremy Stanley wrote: > https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2069607 has > finally been switched to public upstream as of Friday, and contains a lot > more of the rationale behind their breaking change decisions. Thanks. My initial thinking about this issue mirrors what was expressed by James Page in the launchpad comments. [1] In a typical cloud environment, this would not be an issue, as it would not be possible for a malicious user to hijack one of the link-local IMDS addresses. However, as observed elsewhere, not all uses of cloud-init are in actual cloud environments. [2] We provide downloadable VM images that are usable with qemu in non-cloud environments. In those cases, it is possible that there could be a malicious user on the local network link with one of the IMDS addresses. It's an unlikely scenario, and relies on quite a bit of coincidental network access and configuration, but it can happen. Given all of that, I think we should: 1. Update to the latest cloud-init upstream for trixie. It includes a couple of other low-risk bug fixes, too. 2. Update cloud-init in a bookworm point release with a backport of the fix. I haven't looked yet at the complexity involved in backporting the fix to 22.4.2 yet, but will do so now. Given the limited impact of the breaking change, I think documenting it in debian/changelog is sufficient, and we don't need a NEWS entry. Does anybody disagree with the above? noah 1. https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2069607/comments/31 2. https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2069607/comments/32
Bug#1108403: cloud-init: CVE-2024-6174
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2069607 has finally been switched to public upstream as of Friday, and contains a lot more of the rationale behind their breaking change decisions. -- Jeremy Stanley
Bug#1108403: cloud-init: CVE-2024-6174
On 2025-06-30 10:40:26 +0200 (+0200), Thomas Goirand wrote: [...] https://review.opendev.org/c/openstack/nova/+/953732 Hopefully, this will be well received. I however, still think the AHCI driver should be re-added in our cloud kernel though... :/ In particular because, while it may not be all that obvious, it takes a *very* long time for upstream changes in OpenStack to trickle down to deployments in the wild. There are popular public cloud providers running their service on decade-old versions of the software. This also means their users are booting the latest Debian images on relatively ancient host kernels and KVM versions, old libvirt and QEMU, et cetera. But for this particular bug the concern is with users of non-amd64 OpenStack clouds (primarily arm64 but looks like there are also Debian genericcloud images for ppc64el), which could in theory have different drivers selected in the kernel config anyway? Or is that sort of divergence intentionally avoided between architectures? -- Jeremy Stanley
Bug#1108403: cloud-init: CVE-2024-6174
On 6/29/25 18:31, Bastian Blank wrote: Hi Thomas Please fix your emails, they are really hard to read. That's when I reply on my phone, sorry. Any suggestion for a nice mail client on Android? (I'm currently using Boxer) On Sun, Jun 29, 2025 at 05:55:30PM +0200, [email protected] wrote: Could someone see if openstack could finally fix that broken default? There's as much as I know, no way to fix the default. That's why I ask to get OpenStack upstream to fix the default. Something like this, which also removes a lot of special cases. diff --git a/nova/virt/libvirt/blockinfo.py b/nova/virt/libvirt/blockinfo.py index e73cc4d..d12a916 100644 --- a/nova/virt/libvirt/blockinfo.py +++ b/nova/virt/libvirt/blockinfo.py @@ -247,26 +247,7 @@ def get_disk_bus_for_device_type(instance, # Otherwise pick a hypervisor default disk bus if virt_type in ("qemu", "kvm"): if device_type == "cdrom": -guestarch = libvirt_utils.get_arch(image_meta) -if guestarch in ( -obj_fields.Architecture.PPC, -obj_fields.Architecture.PPC64, -obj_fields.Architecture.PPCLE, -obj_fields.Architecture.PPC64LE, -obj_fields.Architecture.S390, -obj_fields.Architecture.S390X, -obj_fields.Architecture.AARCH64): -return "scsi" -machine_type = libvirt_utils.get_machine_type(image_meta) -# NOTE(lyarwood): We can't be any more explicit here as QEMU -# provides a version of the Q35 machine type per release. -# Additionally downstream distributions can also provide their own. -if machine_type and 'q35' in machine_type: -# NOTE(lyarwood): The Q35 machine type does not provide an IDE -# bus and as such we must use a SATA bus for cdroms. -return "sata" -else: -return "ide" +return "virtio" elif device_type == "disk": return "virtio" elif device_type == "floppy": Bastian Thanks for the above. As I don't think it's a good idea to change the behavior of Nova, as it will be a surprise for operators, I made it optional: https://review.opendev.org/c/openstack/nova/+/953732 Hopefully, this will be well received. I however, still think the AHCI driver should be re-added in our cloud kernel though... :/ Cheers, Thomas Goirand (zigo)
Bug#1108403: cloud-init: CVE-2024-6174
Hi Thomas Please fix your emails, they are really hard to read. On Sun, Jun 29, 2025 at 05:55:30PM +0200, [email protected] wrote: > > Could someone see if openstack could finally fix that broken default? > There's as much as I know, no way to fix the default. That's why I ask to get OpenStack upstream to fix the default. Something like this, which also removes a lot of special cases. diff --git a/nova/virt/libvirt/blockinfo.py b/nova/virt/libvirt/blockinfo.py index e73cc4d..d12a916 100644 --- a/nova/virt/libvirt/blockinfo.py +++ b/nova/virt/libvirt/blockinfo.py @@ -247,26 +247,7 @@ def get_disk_bus_for_device_type(instance, # Otherwise pick a hypervisor default disk bus if virt_type in ("qemu", "kvm"): if device_type == "cdrom": -guestarch = libvirt_utils.get_arch(image_meta) -if guestarch in ( -obj_fields.Architecture.PPC, -obj_fields.Architecture.PPC64, -obj_fields.Architecture.PPCLE, -obj_fields.Architecture.PPC64LE, -obj_fields.Architecture.S390, -obj_fields.Architecture.S390X, -obj_fields.Architecture.AARCH64): -return "scsi" -machine_type = libvirt_utils.get_machine_type(image_meta) -# NOTE(lyarwood): We can't be any more explicit here as QEMU -# provides a version of the Q35 machine type per release. -# Additionally downstream distributions can also provide their own. -if machine_type and 'q35' in machine_type: -# NOTE(lyarwood): The Q35 machine type does not provide an IDE -# bus and as such we must use a SATA bus for cdroms. -return "sata" -else: -return "ide" +return "virtio" elif device_type == "disk": return "virtio" elif device_type == "floppy": Bastian -- I have never understood the female capacity to avoid a direct answer to any question. -- Spock, "This Side of Paradise", stardate 3417.3
Bug#1108403: cloud-init: CVE-2024-6174
On Jun 29, 2025 17:31, Bastian Blank wrote: > > On Sun, Jun 29, 2025 at 12:48:20PM +, Jeremy Stanley wrote: > > But since we're talking about a very small subset of clouds right now > > (specifically those with non-amd64 compute nodes), I think the behavior > > change is probably not a major concern. > > Just one. Debian does not support config drive on ahci, only virtio, > when using the smaller genericcloud image. > > Could someone see if openstack could finally fix that broken default? > > Bastian There's as much as I know, no way to fix the default. Only, operators can add the metadata to the flavor or image. Typically to the image in fact, as the lack of AHCI is really just a Debian specificity. Which is why I filled the bug about re-adding AHCI support in the cloud kernel. I think it is very unfortunate you closed that bug so fast, leaving no room for discution. Because of the we (at infomaniak) switched to the non-cloud kernel fearing some customers trying to boot from server backups would ommit the virtio metadata... :( Cheers, Thomas Goirand (zigo)
Bug#1108403: cloud-init: CVE-2024-6174
On Sun, Jun 29, 2025 at 12:48:20PM +, Jeremy Stanley wrote: > But since we're talking about a very small subset of clouds right now > (specifically those with non-amd64 compute nodes), I think the behavior > change is probably not a major concern. Just one. Debian does not support config drive on ahci, only virtio, when using the smaller genericcloud image. Could someone see if openstack could finally fix that broken default? Bastian -- You're dead, Jim. -- McCoy, "The Tholian Web", stardate unknown
Bug#1108403: cloud-init: CVE-2024-6174
On 2025-06-28 18:15:08 +0200 (+0200), [email protected] wrote: [...] FYI, I expect most OpenStack operators to configure a config drive by default, as it is the most reliable metadata source. Yes, the main reason some of them prefer/recommend the network metadata source is that it can be updated over time, while the configdrive content is (currently) frozen at the time its associated server instance is created so things like default gateways, static routes and DNS resolver addresses may grow stale as the operator makes adjustments to their environment. But since we're talking about a very small subset of clouds right now (specifically those with non-amd64 compute nodes), I think the behavior change is probably not a major concern. -- Jeremy Stanley
Bug#1108403: cloud-init: CVE-2024-6174
Source: cloud-init Version: 25.1.1-1 Severity: important Tags: security upstream X-Debbugs-Cc: [email protected], Debian Security Team Hi, The following vulnerability was published for cloud-init. CVE-2024-6174[0]: | When a non-x86 platform is detected, cloud-init grants root access | to a hardcoded url with a local IP address. To prevent this, cloud- | init default configurations disable platform enumeration. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2024-6174 https://www.cve.org/CVERecord?id=CVE-2024-6174 [1] https://github.com/canonical/cloud-init/commit/f43937f0b462734eb9c76700491c18fe4133c8e1 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
