Bug#1108403: (no subject)
On Jun 28, 2025 14:59, Jeremy Stanley wrote: > > On 2025-06-28 09:47:36 +0200 (+0200), Bastian Blank wrote: > [...] > > How that? Most parts of cloud-init are one shot, including the user > > setup. > > If the VM gets its network configuration from metadata instead of > DHCP/SLAAC+RA and isn't relying on configdrive and isn't falling > back to using network settings cached into /etc from a prior boot > (and is running on a non-amd64 arch), then it can come up with no > reachable network. That combination of factors should be > exceptionally rare however. > > The more likely scenario, you're right, is that updated images fail > when trying to create and boot a new VM from them for the first > time, but that's probably far less problematic since users can > typically roll back to an older version of the image or adjust their > options to e.g. turn on configdrive when available. > -- > Jeremy Stanley FYI, I expect most OpenStack operators to configure a config drive by default, as it is the most reliable metadata source. Thomas Goirand
Bug#1108403: (no subject)
On 2025-06-28 09:47:36 +0200 (+0200), Bastian Blank wrote: [...] How that? Most parts of cloud-init are one shot, including the user setup. If the VM gets its network configuration from metadata instead of DHCP/SLAAC+RA and isn't relying on configdrive and isn't falling back to using network settings cached into /etc from a prior boot (and is running on a non-amd64 arch), then it can come up with no reachable network. That combination of factors should be exceptionally rare however. The more likely scenario, you're right, is that updated images fail when trying to create and boot a new VM from them for the first time, but that's probably far less problematic since users can typically roll back to an older version of the image or adjust their options to e.g. turn on configdrive when available. -- Jeremy Stanley
Bug#1108403: (no subject)
On Fri, Jun 27, 2025 at 11:51:08PM +, Jeremy Stanley wrote: > The biggest risk I see with shipping it in stable is that an apt upgrade of > cloud-init could leave some virtual machines in these environments > unreachable after a reboot. How that? Most parts of cloud-init are one shot, including the user setup. Bastian -- Lots of people drink from the wrong bottle sometimes. -- Edith Keeler, "The City on the Edge of Forever", stardate unknown
Bug#1108403: (no subject)
On 2025-06-27 15:36:26 -0400 (-0400), Noah Meyerhans wrote: [...] There are potential workarounds, but they're not necessarily trivial for users who are operating a cloud environment that they don't control. The primary workaround is to use a datadrive for VM metadata, rather than a network service, but that's a choice made by the cloud operator. [...] I was read in on this back early in the year (in my capacity as an OpenStack vulnerability manager even though the vulnerability itself doesn't really affect typical OpenStack deployments), but sadly the LP bug seems to still be private which makes talking about specific mitigations for the vulnerability and workarounds for the new behavior difficult. Non-amd64 OpenStack environments are not common, though they do exist and I have access to some. This is primarily arm64 with maybe a smattering of aging ppc64 and s390x, and I've heard tell of riscv experiments in some organizations. That said, behavior changes in new versions of software necessitate that users ask the operators of their cloud services to make certain new configurations possible, I don't see this as being all that different if it were just coming in a new major Debian version. The biggest risk I see with shipping it in stable is that an apt upgrade of cloud-init could leave some virtual machines in these environments unreachable after a reboot. It's very hard to estimate the actual impact due to the various factors involved, as well as overall lack of knowledge about the number and sizes of those environments. The OpenInfra Foundation does run surveys which include questions about some of this (architecture, deployment scale...) but it's elective self-reporting so at best only an indicator of proportion, assuming related biases don't skew responses to the point of complete uselessness in this case. -- Jeremy Stanley signature.asc Description: PGP signature
Bug#1108403: (no subject)
[email protected] Cc: Bcc: Subject: Re: Bug#1108403: cloud-init: CVE-2024-6174 Reply-To: In-Reply-To: <[email protected]> On Fri, Jun 27, 2025 at 09:14:17PM +0200, Salvatore Bonaccorso wrote: > 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. My inclination is to pull in the latest upstream patch release, 25.1.4 (we're currently at 25.1.1 in trixie). However, the fix for CVE-2024-6174 does introduce a functionality change that may be disruptive in some less common environments (notably non-amd64 OpenStack). There are potential workarounds, but they're not necessarily trivial for users who are operating a cloud environment that they don't control. The primary workaround is to use a datadrive for VM metadata, rather than a network service, but that's a choice made by the cloud operator. Thomas, as OpenStack maintainer, do you have any insight into just how disruptive this change is likely to be? Still researching this one... noah
