Control: severity -1 minor Control: tags -1 wontfix Salvatore Bonaccorso <[email protected]> writes:
> The following vulnerability was published for docker.io. > > CVE-2025-54410[0]: > | Moby is an open source container framework developed by Docker Inc. > | that is distributed as Docker Engine, Mirantis Container Runtime, > | and various other downstream projects/products. A firewalld > | vulnerability affects Moby releases before 28.0.0. When firewalld > | reloads, Docker fails to re-create iptables rules that isolate > | bridge networks, allowing any container to access all ports on any > | other container across different bridge networks on the same host. > | This breaks network segmentation between containers that should be > | isolated, creating significant risk in multi-tenant environments. > | Only containers in --internal networks remain protected. Workarounds > | include reloading firewalld and either restarting the docker daemon, > | re-creating bridge networks, or using rootless mode. Maintainers > | anticipate a fix for this issue in version 25.0.13. > > > 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-2025-54410 > https://www.cve.org/CVERecord?id=CVE-2025-54410 > [1] https://github.com/moby/moby/security/advisories/GHSA-4vq8-7jfc-9cvp I worked on backporting the relevant upstream patches and published my WIP branch to https://salsa.debian.org/go-team/packages/docker/-/merge_requests/17 Additionally, I've asked Tianon for feedback and got some eyes from the original author Rob on the issue. To quote from https://salsa.debian.org/go-team/packages/docker/-/merge_requests/17#note_658404 > I thought I'd try it out on a Trixie VM, and it got confusing! ... > A firewalld reload didn't delete the rules like it does in Bookworm. It turns > out Trixie is using firewalld 2.x, with its default nftables backend - and > firewalld has a change to not flush iptables rules in that case. > So, it may not be worth jumping through the hoops to make the patch - unless > users are likely to be switching firewalld to the iptables backend. > The patch looks good though, I gave it a go with firewalld using its iptables > backend. (The patch also stops a firewalld reload from re-creating rules for > deleted networks. That does affect Trixe with its newer firewalld, because > although rules aren't flushed and Docker doesn't need to restore them, it > doesn't know that. That's not what the CVE was about though.) I agree with Tianon that while we have a patch that appars to be correct, the risk of introducing unintended regressions is too high for fixing this minor issue. As such, I'm marking this bug as "wontfix" with severity minor. I'm leaving this bug open, and plan to close it with an upcoming (major) version upgrade. If you think there are compelling reasons for uploading this patch to unstable or even stable, please reply to this bug! Thanks for everyone involved in this issues. Somethings not doing anything is indeed the best outcome :-) Best, -rt
