[pkg-go] Bug#1117966: Fwd: Bug#1117966: podman: CVE-2025-4953
Tom Sweeney
tom.sweeney at redhat.com
Mon Dec 8 20:47:36 GMT 2025
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 at 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 at testvm:~# echo $?
>> 0
>> root at 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 at testvm:~# nginx_fqin=docker.io/nginx bash ./CVE-2025-4953.sh
>> [...]
>> NOT VULNERABLE
>> root at 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 at 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 at 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
>
More information about the Pkg-go-maintainers
mailing list