Chris, please see the ask about adding your bash test script for 4953 to
a more public location. Apologies for not including you in the original
conversation here.
t
On 12/4/25 2:55 PM, Salvatore Bonaccorso wrote:
Hi Reinhard,
Tom, thanks for the answer and details on the issue.
On Thu, Dec 04, 2025 at 06:17:12AM -0500, Reinhard Tartler wrote:
Control: found -1 4.3.1+ds1-8+deb12u1
Control: fixed -1 5.4.2+ds1-2
On 2025-12-03 17:31, Tom Sweeney wrote:
Hi Reinhard, Salvatore and others,
The fix for CVE-2025-4953 for Podman was tightly entwined with the
fixes for CVE-2024-11218 and CVE-2024-9675, and we fixed both CVEs
with one PR in Podman v4.2 and neglected to do a good job noting that
upstream. We'd actually unknowingly fixed CVE-2025-4953 with fixes
for the other two CVEs in Buildah.
So in the Podman v4.2-rhel fix, the PR that fixed this was:
https://github.com/containers/podman/pull/25173 and our Jira card,
which I think you can get to is:
https://issues.redhat.com/browse/RHEL-113900. I've added a note to
the GitHub PR to include CVE-2025-4953 in my last comment, apologies
for neglecting that earlier.
In Buildah, the fixes for CVE-2024-9675 got in as a bonus with
"[release-1.27] Properly validate cache IDs and sources" -
https://github.com/containers/buildah/pull/5797 and then "Backport fix
for CVE-2024-11218 [1] " -
https://github.com/containers/buildah/pull/5946, both of which were
part of Buildah v1.27.6 which was then vendored into Podman 4.2-rhel
as noted above.
I've attempted to add you to our internal test plan document for
CVE-2025-4953
(https://docs.google.com/document/d/1n7qtou8kfxwaeWM2fJv2LsgLCM8Y51aBxPo5ZxzKQf8/edit?tab=t.0)
in case that is all helpful.
That's actually very helpful. Tom, I noticed that the Google doc is not
publicly accessible. Do I have your permission to attach the tester bash
script publicly to this bug? It does not come with any license or
distribution terms, but I do think it would be useful if other people than
me were able to run it to verify the fix.
Reinhard, I'm fine with attaching the bash script publicly, however, I'd
like to get a head nod from Chris Evich, who created that script. I
don't believe he will have an issue, but just to be safe.
Chris?
In any case, I've been running the shell script in a Debian/sid VM and got
as result:
root@testvm:~# nginx_fqin=docker.io/nginx bash ./CVE-2025-4953.sh
[...]
STEP 2/2: RUN --mount=type=bind,dst=/dst,source=/,z,rw chown 1000:1000
/dst ; chmod 777 /dst ; touch /dst/is_vulnerable && chmod 4777
/dst/is_vulnerab
le && ls -la /dst && echo "Waiting 3 seconds for the exploit to
trigger..." && sleep 3
[ 270.849865] podman0: port 2(veth1) entered blocking state
[ 270.850280] podman0: port 2(veth1) entered disabled state
[ 270.850666] veth1: entered allmulticast mode
[ 270.851026] veth1: entered promiscuous mode
[ 270.851558] podman0: port 2(veth1) entered blocking state
[ 270.851995] podman0: port 2(veth1) entered forwarding state
total 12
drwxrwxrwx 1 1000 1000 4096 Dec 4 10:45 .
dr-xr-xr-x 1 root root 4096 Dec 4 10:45 ..
-rw------- 1 root root 283 Dec 4 10:45 Dockerfile
-rwsrwxrwx 1 root root 0 Dec 4 10:45 is_vulnerable
Waiting 3 seconds for the exploit to trigger...
[ 274.019740] podman0: port 2(veth1) entered disabled state
[ 274.020374] veth1 (unregistering): left allmulticast mode
[ 274.020739] veth1 (unregistering): left promiscuous mode
[ 274.021132] podman0: port 2(veth1) entered disabled state
COMMIT
--> 9004270ae03b
9004270ae03b4f1e8dfd8bec203711f045bb5c2ca66a6825ce9a66be7c137fae
##### Build completed, waiting for watcher to process... #####
##### Watcher still running, terminating it #####
Session terminated, killing shell... ...killed.
##### Checking for exploit success #####
##### Watcher process (7028) exited as expected
!!!!! test file (/tmp/tmp.uLyGmtXw34/testfile.BLqJPW) not found
[ 279.326073] podman0: port 1(veth0) entered disabled state
[ 279.326653] veth0 (unregistering): left allmulticast mode
[ 279.326999] veth0 (unregistering): left promiscuous mode
[ 279.327321] podman0: port 1(veth0) entered disabled state
NOT VULNERABLE
root@testvm:~# echo $?
0
root@testvm:~# dpkg -l | grep podman
ii podman 5.7.0+ds2-3 amd64
tool to manage containers and pods
I've done the same in Trixie, and got:
root@testvm:~# nginx_fqin=docker.io/nginx bash ./CVE-2025-4953.sh
[...]
NOT VULNERABLE
root@testvm:~# dpkg -l | grep podman
ii podman 5.4.2+ds1-2+b1
amd64 tool to manage containers and pods
I've done the same again in bookworm (here I had to install ca-certificates
manually, was automatically available for Trixie and Forky):
root@testvm:~# nginx_fqin=docker.io/nginx bash ./CVE-2025-4953.sh
[...]
##### Checking for exploit success #####
##### Watcher process (8595) exited as expected
##### test file (/tmp/tmp.Nkvs61dDUd/testfile.7LAb3E) found
##### test file contents: '7774777' indicate vulnerability
[ 148.278025] podman0: port 1(veth0) entered disabled state
[ 148.278654] device veth0 left promiscuous mode
[ 148.278940] podman0: port 1(veth0) entered disabled state
VULNERABLE
root@testvm:~# dpkg -l | grep podman
ii podman 4.3.1+ds1-8+deb12u1+b1 amd64
engine to run OCI-based containers in Pods
I conclude that the script works and we have:
sid/forky: NOT AFFECTED
trixie: NOT AFFECTED
bookworm: AFFECTED
Salvatore, currently this issue is currently marked in the security tracker
as:
CVE-2025-4953 (A flaw was found in Podman. In a Containerfile or Podman,
data written ...)
- podman <unfixed> (bug #1117966)
[trixie] - podman <no-dsa> (Minor issue)
- libpod <removed>
[bookworm] - libpod <no-dsa> (Minor issue)
[bullseye] - libpod <postponed> (Minor issue)
NOTE: https://bugzilla.redhat.com/show_bug.cgi?id=2367235
TODO: check details
I updated it right now to
https://salsa.debian.org/security-tracker-team/security-tracker/-/commit/7028c573ff439d0908de377901742287673051b6
. This is not completely correct, technically we would need some sort
of source fix in podman to be identified, or maybe reassign it to
buildah source and consider it fixed with the version addressing both
related CVEs? I'm not having right now a better idea for proper
tracking though.
Based on the above, I'm inclined to close this bug, and ask the security
team to update the above in
https://salsa.debian.org/security-tracker-team/security-tracker/-/blob/master/data/CVE/list?ref_type=heads
to indicate that Sid and Trixie are fixed or non-affected. Is this something
that want to fix in bookworm and bullseye? While Bookworm has an EOL of June
2026, this issue is marked as "minor", so I defer to your judgement whether
this warrants an DSA update. I'm even less sure about "bullseye", which is
past EOL but may or may not cover issues like this via LTS updates. Again,
let me know what's appropriate here.
No I to not think we need to address the issue for bookworm and older
in a DSA. LTS team propably can as well mark it just as <ignored> now.
So IMHO you can as well close the bug with the appropriate version
which bumped the version of buildah sufficently so to address the
issue.
Regards,
Salvatore