shadow-utils (aka shadow) 4.4 through 4.17.0 establishes a default /etc/subuid behavior (e.g., uid 100000 through 165535 for the first user account) that can realistically conflict with the uids of users defined on locally administered networks, potentially leading to account takeover, e.g., by leveraging newuidmap for access to an NFS home directory (or same-host resources in the case of remote logins by these local network users). NOTE: it may also be argued that system administrators should not have assigned uids, within local networks, that are within the range that can occur in /etc/subuid.
This breaks effectively all realistic default usage of podman rootless containers for new installs (or new users in existing installs), which is a pretty large impact. As is it would mean everyone who wants to do that would need to ensure their provisioned systems re add the uid ranges. We have the inverse problem too in that applying this update won’t actually fix the problem if somehow existing uids do overlap! Really I think the deliverable for this CVE should probably be a tool that can be run to analyze/adjust if there is actually a clash, not just disable the functionality globally by default.
yeah, breaking podman out of the box is pretty bad. It broke some openQA tests, and I just found my way here trying to figure out why.
Dug into this and found some discussion, particularly at https://github.com/shadow-maint/shadow/issues/1157 . I think the relatively 'low' range 100000 through 165535 was specifically chosen to avoid conflict with FreeIPA, which 'reserves' a range of 200000 IPs on install. By default it does this to pick the start of the range: random.randint(1, 10000) * 200000 which means it will never start lower than 200000, but it might use *any* UID above 200000. However, this makes a conflict much more likely with a large non-FreeIPA site, if it just started at 1000 and counted up, or whatever - that seems to be the situation the reporter of the github issue found themselves in.
FYI there is a broader discussion going on at https://bugzilla.redhat.com/show_bug.cgi?id=2382662
This issue has been addressed in the following products: Red Hat Enterprise Linux 10 Via RHSA-2025:20145 https://access.redhat.com/errata/RHSA-2025:20145
This issue has been addressed in the following products: Red Hat Enterprise Linux 9 Via RHSA-2025:20559 https://access.redhat.com/errata/RHSA-2025:20559