Files
podman/libpod
Matthew Heon 2c6dadd724 Fix a locking bug in that could cause a double-unlock
The `cleanupExecBundle` function was only meant to be called on a
locked container, as it does some state mutation operations. It
also has a timed wait (if the directory is busy and can't be
removed yet, give it a few milliseconds) in which it deliberately
yields the lock to not block the container for that time.

The `healthCheckExec()` function calls `cleanupExecBundle` out of
a `defer` block. This is after the `defer c.lock.Unlock()` so it
fires afterwards when the function returns, so we're normally
fine - the container is still locked when our defer runs. The
problem is that `healthCheckExec()` also unlocks the container
during the expensive exec operation, and can actually fail and
return while not holding the lock - meaning our `defer` can fire
on an unlocked container, leading to a potential double unlock
in `cleanupExecBundle`.

We could, potentially, re-lock the container after the exec
occurs, but we're actually waiting for a `select` to trigger to
end the function, so that's not a good solution. Instead, just
re-lock (if necessary) in the defer, before invoking
`cleanupExecBundle()`. The `defer c.lock.Unlock()` will fire
right after and unlock after us.

Fixes #26968

Signed-off-by: Matthew Heon <matthew.heon@pm.me>
2025-09-03 10:19:37 -04:00
..
2024-09-03 15:14:15 +02:00
2024-02-08 09:35:39 -05:00
2024-02-08 09:35:39 -05:00
2024-02-08 09:35:39 -05:00
2024-02-08 09:35:39 -05:00
2024-02-08 09:35:39 -05:00
2024-02-08 09:35:39 -05:00
2024-02-08 09:35:39 -05:00
2024-02-08 09:35:39 -05:00
2024-02-08 09:35:39 -05:00
2024-02-08 09:35:39 -05:00
2024-02-08 09:35:39 -05:00
2024-02-08 09:35:39 -05:00
2024-02-08 09:35:39 -05:00
2024-02-08 09:35:39 -05:00