July 2026 - openstack-discuss - lists.openstack.org

[debian][security] End of support for Victoria, Wallaby, Xena, Yoga on top of Debian Bullseye
by Thomas Goirand 07 Sep '26

07 Sep '26

Dear OpenStack Debian users, As Debian 11, aka Bullseye, is getting out of LTS support from Debian, I'm hereby also announcing end of security support from my side for the matching OpenStack release. This means that, at some (rare) exception for very grave issues that wont be too hard to backport, I will *NOT* backport security patches for Victoria, Wallaby, Xena and Yoga. I will continue to support Zed, including in Bullseye, through the usual backport repository at osbpo.debian.net. If you're running Debian Bullseye with Victoria, Wallaby, Xena, Yoga, I very much strongly encourage upgrading to a supported version, preferably at least bookworm-zed. As a reminder, I am tracking CVEs, OSSA and OSSN backports at: https://wiki.debian.org/OpenStack/CVE-2026 This doesn't show what I also backported to Bullseye, like the fix for CVE-2026-43001 and friends (OSSA-2026-015), as it wouldn't fit on a decently large screen, but some have been done. I strongly also encourage the use of the osbpo.debian.net repository even for OpenStack releases maintained in Debian Stable or oldstable, as it takes more time for security fixes to reach official repositories, than it takes me to just push fixes to the unofficial repositories (which is fully automated backport builds). If you haven't done so, these backports repositories can be activated with extrepo. For example, for Epoxy on top of Trixie: apt-get install extrepo extrepo enable openstack_epoxy apt-get update Last thing: I'm currently working on OSSA-2026-027 to OSSA-2026-031. Fixes for them should be available today on all supported versions of OpenStack. Best regards, Thomas Goirand (zigo)

2 3

[nova] Proposals for changes to nova-core
by Stephen Finucane 03 Sep '26

03 Sep '26

[BCC current nova core group, not all of whom were present today] o/ During today's nova PTG sessions, we discussed Sean Mooney's recent proposal [1] to introduce new nova-approver and nova-reviewer groups, akin to the model used by Ironic in recent releases. The conversation was initially expected to focus on the onboarding of new nova cores, but ended up turning into a discussion on how best to use the experience of SMEs from other OpenStack services with integration in nova to make progress on their features in a timely manner. This was heavily inspired by discussions between the Ironic and Nova teams earlier this week. During the discussion, it became clear that there were a variety of potential options on the table and many of the Nova cores present had different and often competing preferences. In order to break the deadlock, we agreed to codify four proposals into changes to the Nova contributor docs submitted to Gerrit. This is now done, and the four proposals can be found here: * https://review.opendev.org/c/openstack/nova/+/986141 (option 1) * https://review.opendev.org/c/openstack/nova/+/986142 (option 2) * https://review.opendev.org/c/openstack/nova/+/986143 (option 3) * https://review.opendev.org/c/openstack/nova/+/986144 (option 4) I have attempted to capture the intent of the proposals in the changes themselves, but for the avoidance of confusion I will repeat the guidance here, in a bullet point format: * These patches *should not* be merged yet. Nova cores are asked to +1 the options that they are *okay with* and -1 those that are *not okay with*. A +0 vote is considered neutral and is not included. This is known as "Approval Voting". * Small issues with wording and typos can be noted, but should not affect the overall vote: we can address these issues before we merge the patch. * Additionally, none of these proposals should imply a change in our general policy for onboarding new cores. * We will proceed with the most popular proposal for the remainder of the H cycle and evaluate the outcome during the next PTG (expected in October 2026). At that point, we will decide whether to persist with the proposal and merge this patch, or make changes. The ask is for all existing nova cores to weigh in on the proposals and explicitly submit a -1, 0, or +1 vote on each patch. I will stress again that we are not looking for a solution that is everyone's favoured solution as such a solution does not appear to exist. Rather, we are looking for a solution that is *acceptable* to the largest percentage of existing nova cores. I propose that we give it a week for people to assess the options and provide their opinions. At that point we'll proceed with the chosen proposal for the duration of the H cycle. Cheers, Stephen [1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack…

1 2

[tc][ptls] OpenStack User Survey Revision - Next Steps
by Allison Price 26 Aug '26

26 Aug '26

Hi everyone, Amy Marrich and I met today to discuss the next steps in incorporating the feedback from the PTG [1] into revisions for the OpenStack User Survey. As a next step, we are sharing an etherpad with the full set of OpenStack User Survey questions [2]. I’d like to ask everyone, especially TC member and PTLs to review the questions and share any edits you think would help the user survey more accurately capture OpenStack deployment data. Specifically, the following projects have custom questions added that are tagged and should be reviewed. Each project can have a maximum of three questions. Barbican Cinder Designate Glance Heat Interop Ironic Keystone Kolla Manila Neutron Nova Octavia RefStack Sahara Self-Healing SIG Swift Telemetry TripleO Trove I18n All edits and additions must be made by Monday, August 24 to be incorporated into the 2027 version of the OpenStack User Survey. If you have any questions, please let me know. Cheers, Allison [1] https://etherpad.opendev.org/p/OpenStack-User-Survey-Streamlining [2] https://etherpad.opendev.org/p/OpenStackUserSurveyRev

5 10

[openstack][nova]qemu system wont release memory
by Nguyễn Hữu Khôi 25 Aug '26

25 Aug '26

Hello. I have an OpenStack instance that was using 14GB out of 16GB of memory. Later, when it was using only 4GB, I checked the QEMU process on the compute node, and it was still consuming 14GB, this means memory isn't released when usage decreases. Do we have solutions for this? I use Ubuntu 24.04 instances. Nguyen Huu Khoi

2 13

kolla-ansible support for Ubuntu 2024.04/ARM64 ?
by dariusz.bursztynowski＠pw.edu.pl 18 Aug '26

18 Aug '26

Hello, Are there plans for kolla-ansible to support Ubuntu 24.04 / ARM64 (e.g., to have LTS support for Raspberry Pi 5)? Best regards, Dariusz Bursztynowski

2 1

[policy][keystone][horizon] scope mismatch between horizon and keystone
by Takashi Kajinami 07 Aug '26

07 Aug '26

While digging into the unit tests failures recently surfacing after enforce_scope option was removed from oslo.policy[1], I discovered mismatch between current keystone policy rules and the expectation from horizon. I may need some input from both sides to fix this. [1] bugs.launchpad.net/bugs/2161292 Horizon uses domain-scoped token for most of the keystone API calls, when the following two options[2] are both true. [2] https://opendev.org/openstack/horizon/src/commit/f76caf9d083cee8bd76f69e805… --- # Set this to True if running on a multi-domain model. When this is enabled, it # will require the user to enter the Domain name in addition to the username # for login. OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = False # When multidomain support is enabled and user has any roles in a domain, # Horizon will mostly attempt to use domain scope for calls to Keystone. # This behavior does not work properly with some policy combinations, # and can be disabled here. OPENSTACK_KEYSTONE_PREFER_DOMAIN_TOKEN = True --- When this behavior is enabled, horizon uses domain-scoped context to evaluate policy rules, which is consistent with its API call behaviors. However, on the other hand, keystone permits access to some of the system-wide resources only for project scope and system scope. Identity provider is one example of such resources. The described inconsistency between the expected token scope is the problem and this is the core reason why unit tests started failing. This inconsistency means that, when multi domain support is enabled, horizon attempts to use domain scope token to most of keystone api calls, but some of them are actually rejected by keystone due to scope enforcement within keystone. Current horizon doesn't implement fallback between two different scopes, so unless multi domain support is disabled or domain role is removed, the user can't manipulate these resources any more. There are a few options I could think of now. 1. Allow all keystone resources to be manipulated by domain scope 2. Get rid of that "OPENSTACK_KEYSTONE_PREFER_DOMAIN_TOKEN" feature completely given that fact that domain scope is not really intended to be used to manage system-wide resources in keystone and project-scope should be used instead. 3. Make horizon use appropriate scope according to the target resources. 4. Implement scope fallback mechanism within horizon. I'm sending this email maikly to hear from the keystone folks if option 1 is something acceptable. I don't fully understand the context behind allowing access of these resources to only project scope and system scope. If the current scope may not be changed, we'd select 2 or 3, but I find 3 and 4 quite tricky, and if keystone expects only project scope or system scope for system-wide resources then 2 might be the only feasible solution, I guess. Thank you, Takashi -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

2 3

[Cinder/Nova, NVME-TCP] Issue with multipath and devstack
by Anthony Galica 06 Aug '26

06 Aug '26

Hi everyone, I'm having an issue with multipath on devstack. I'm currently on the master branch (synced as of ~2mo ago). I am working on implementing NVME-TCP, and whenever initialize_connection is called multipath=False is always set. Despite what I return it results in a single path (I actually get the same result with iSCSI as well, and did not try FC at this time). I believe the issue to be environmental and I was hoping someone could help me figure out what I'm missing. I want to focus on NVME-TCP here as I know the iSCSI configuration works with a correct setup. According to cinder-volume.log, this is the connection information returned by my driver (note multiple portals): Connection info returned from driver {'target_nqn': 'nqn.1994-04.jp.co.hitachi:nvme:storage-subsystem-sn.8-10045-nvmssid.00095', 'vol_uuid': '5080273d-0000-0000-0060-e828273d6c03', 'ns_id': 1, 'portals': [['172.25.59.70', '4420', 'tcp'], ['172.25.59.71', '4420', 'tcp']], 'target_discovered': False, 'discard': False, 'qos_specs': None, 'access_mode': 'rw', 'encrypted': False, 'cacheable': False, 'driver_volume_type': 'nvmeof', 'attachment_id': 'cd3938ed-7e4e-4232-9648-e898d99eb32b', 'enforce_multipath': True} [00;33m{{(pid=11654) _connection_create /opt/stack/cinder/cinder/volume/manager.py:4925}}[00m I'm able to ping both portals: stack@devstack-93-52:~/devstack$ ping 172.25.59.70 PING 172.25.59.70 (172.25.59.70) 56(84) bytes of data. 64 bytes from 172.25.59.70: icmp_seq=1 ttl=63 time=0.463 ms 64 bytes from 172.25.59.70: icmp_seq=2 ttl=63 time=0.514 ms 64 bytes from 172.25.59.70: icmp_seq=3 ttl=63 time=0.486 ms ^C --- 172.25.59.70 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2013ms rtt min/avg/max/mdev = 0.463/0.487/0.514/0.020 ms stack@devstack-93-52:~/devstack$ ping 172.25.59.71 PING 172.25.59.71 (172.25.59.71) 56(84) bytes of data. 64 bytes from 172.25.59.71: icmp_seq=1 ttl=63 time=0.430 ms 64 bytes from 172.25.59.71: icmp_seq=2 ttl=63 time=0.422 ms 64 bytes from 172.25.59.71: icmp_seq=3 ttl=63 time=0.494 ms 64 bytes from 172.25.59.71: icmp_seq=4 ttl=63 time=0.502 ms ^C --- 172.25.59.71 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3087ms rtt min/avg/max/mdev = 0.422/0.462/0.502/0.036 ms I have configured multipath.conf like this (this configuration works with a different product as well): defaults { user_friendly_names yes } devices { device { vendor "HITACHI" product "OPEN-.*" # Group paths by priority to leverage ALUA path_grouping_policy "group_by_prio" prio "alua" path_checker "tur" failback "immediate" # Queue I/O when all paths are down to prevent filesystem read-only errors on VMs no_path_retry "queue" # Round-robin I/O policy settings rr_weight "uniform" rr_min_io_rq 1 } } In Nova, I updated the config to add the highlighted (last two) items: [libvirt] live_migration_uri = qemu+ssh://stack@%s/system cpu_models = Nehalem cpu_mode = custom virt_type = qemu volume_use_multipath = True volume_enforce_multipath = True I also validated the NVMe multipath parameters: stack@devstack-93-52:~/devstack$ cat /sys/module/nvme_core/parameters/multipath Y After all changes I made, I also restarted all devstack services. I also validated the configuration on the actual storage, of course. Still no dice. Anyone have any ideas as to what I might be missing? Thanks, Anthony

5 6

[OSSA-2026-031] OpenStack Swift: Proxy denial of service via Accept header (CVE-2026-pending)
by Goutham Pacha Ravi 05 Aug '26

05 Aug '26

============================================================== OSSA-2026-031: Swift proxy denial of service via Accept header ============================================================== :Date: July 28, 2026 :CVE: CVE-2026-pending Affects ~~~~~~~ - Swift: >=1.9.1 <2.35.4, >=2.36.0 <2.36.3, >=2.37.0 <2.37.3, ==2.38.0 Description ~~~~~~~~~~~ Christian Schwede from NVIDIA reported a denial of service vulnerability in Swift's proxy server. The Accept header parser is vulnerable to catastrophic regular expression backtracking. An unauthenticated attacker can send crafted requests that exhaust proxy worker threads, rendering the service unavailable. All deployments running Swift proxy with versions between 1.9.1 and the fixed releases listed below are affected. Patches ~~~~~~~ - https://review.opendev.org/998953 (2025.1/epoxy) - https://review.opendev.org/998952 (2025.2/flamingo) - https://review.opendev.org/998951 (2026.1/gazpacho) - https://review.opendev.org/998950 (2026.2/hibiscus (development)) Credits ~~~~~~~ - Christian Schwede from NVIDIA References ~~~~~~~~~~ - https://launchpad.net/bugs/2158771 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-pending -- Goutham Pacha Ravi OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

1 1

[OSSA-2026-030] OpenStack Swift: S3API header authorization bypass (CVE-2026-pending)
by Goutham Pacha Ravi 05 Aug '26

05 Aug '26

====================================================== OSSA-2026-030: Swift S3API header authorization bypass ====================================================== :Date: July 28, 2026 :CVE: CVE-2026-pending, CVE-2026-pending Affects ~~~~~~~ - Swift: >=2.18.0 <2.35.4, >=2.36.0 <2.36.3, >=2.37.0 <2.37.3, ==2.38.0 Description ~~~~~~~~~~~ Christian Schwede from NVIDIA reported two authorization bypass vulnerabilities in Swift's S3API middleware. Insufficient validation of request headers allows an attacker to copy and read objects belonging to other tenants. The first issue affects the default ``s3_acl=false`` configuration; the second affects deployments with ``s3_acl=true``. Both require the attacker to know the target container and object names. All deployments using the S3API middleware with versions between 2.18.0 and the fixed releases listed below are affected. Patches ~~~~~~~ - https://review.opendev.org/998948 (2025.1/epoxy) - https://review.opendev.org/998949 (2025.1/epoxy) - https://review.opendev.org/998946 (2025.2/flamingo) - https://review.opendev.org/998947 (2025.2/flamingo) - https://review.opendev.org/998944 (2026.1/gazpacho) - https://review.opendev.org/998945 (2026.1/gazpacho) - https://review.opendev.org/998942 (2026.2/hibiscus (development)) - https://review.opendev.org/998943 (2026.2/hibiscus (development)) Credits ~~~~~~~ - Christian Schwede from NVIDIA References ~~~~~~~~~~ - https://launchpad.net/bugs/2158733 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-pending - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-pending -- Goutham Pacha Ravi OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

1 1

[OSSA-2026-007] OpenStack Keystone: LDAP identity backend does not convert enabled attribute to boolean (CVE PENDING)
by Goutham Pacha Ravi 05 Aug '26

05 Aug '26

================================================================================== OSSA-2026-007: LDAP identity backend does not convert enabled attribute to boolean ================================================================================== :Date: April 14, 2026 :CVE: CVE-2026-pending Affects ~~~~~~~ - Keystone: >=8.0.0 <25.0.1, >=26.0.0 <26.1.1, >=27.0.0 <27.0.1, >=28.0.0 <28.0.1 Description ~~~~~~~~~~~ Benedikt Trefzer and Andrew Bogott independently reported a vulnerability in the Keystone LDAP identity backend. When the user_enabled_invert configuration option was False (the default), Keystone did not correctly interpret the LDAP enabled attribute, causing users disabled in LDAP to be treated as enabled and allowed to authenticate. Deployments using the LDAP identity backend without user_enabled_invert=True or user_enabled_emulation are affected. Patches ~~~~~~~ -https://review.opendev.org/982409 (2024.2/dalmatian) -https://review.opendev.org/982408 (2025.1/epoxy) -https://review.opendev.org/982407 (2025.2/flamingo) -https://review.opendev.org/958205 (2026.1/gazpacho) Credits ~~~~~~~ - Benedikt Trefzer from Cirrax GmbH (CVE-2026-pending) - Andrew Bogott from Wikimedia Foundation (CVE-2026-pending) - Grzegorz Grasza from Red Hat (CVE-2026-pending) References ~~~~~~~~~~ -https://launchpad.net/bugs/2121152 -https://launchpad.net/bugs/2141713 Notes ~~~~~ - To work around this vulnerability, set user_enabled_invert=True and use an LDAP attribute with inverted semantics such as nsAccountLock, or use user_enabled_emulation with group-based enabled status. - A CVE request was filed with MITRE on 2026-04-10. - The fix was merged on the master branch before the stable/2026.1 branch was cut, so no specific stable/2026.1 patch exists. The fix is included in the gazpacho (29.0.0) release. -- Goutham Pacha Ravi (gouthamr) OpenStack Vulnerability Management Team

1 1