The cleaning is condition on this variable being set. So let's unset it
after we clean the resources.
Signed-off-by: Rodrigo Campos <rodrigo@amutable.com>
(cherry picked from commit e79bff701a)
We are creating the interface for every test, but there is only one
using it. Let's just call the function to create the netdev on the test
that uses it.
I guess that was the reason we had the "ip link del ..." in teardown.
Because in a lot of tests we were just creating and deleting the
interface on the host.
While we are there, as suggested by lifubang, let's make the "ip link
add" line specify the mtu and mac addr. This way, the interface is not
created without that info and we race with host daemons (like udev) that
_might_ want to change it.
Signed-off-by: Rodrigo Campos <rodrigo@amutable.com>
(cherry picked from commit b16ed9a0b8)
Once we add a new network device, systemd-udev may execute some rules.
In particular, we see that on Fedora it sets the MAC address (presumably
based on the host name and device name). This setting races with ours
'ip link set address', as a result, "checkpoint and restore with netdevice"
test sometimes fails telling the MAC address is not as expected.
In the future there may be some other udev rules etc., so the overall
solution is to wait until systemd-udev is finished applying the rules,
thus eliminating the race.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
(cherry picked from commit b2ada85ed3)
Given that the majority of reviewers favor the 'nr_inodes=2' retry logic,
we propose reverting #5353 and implementing the new approach.
1. Revert "libct: add a fallback for nr_inodes=2"
This reverts commit 79ac57770f.
2. Revert "libct: Enforce nr_inodes=2 to fix Focal mount errors"
This reverts commit feea25820e.
3. The new approach:
On most kernels `nr_inodes=1` works fine. However, Ubuntu 20.04 (Focal) with
the official 5.4 kernel carries a private patch in "mm/shmem.c" that rejects
`nr_inodes<2`, so retry with `nr_inodes=2` here.
For reference, search for "case Opt_nr_inodes" in:
https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal/plain/mm/shmem.c?h=Ubuntu-5.4.0-216.236
Signed-off-by: lifubang <lifubang@acmcoder.com>
(cherry picked from commit a5690a084d)
Signed-off-by: lifubang <lifubang@acmcoder.com>
We don't know whether some kernels will fail with "nr_inodes=2",
so let's fall back to mount a tmpfs without "nr_inodes".
Signed-off-by: lifubang <lifubang@acmcoder.com>
(cherry picked from commit 79ac57770f)
Signed-off-by: lifubang <lifubang@aliyun.com>
On most kernels `nr_inodes=1` works fine. However, Ubuntu 20.04 (Focal) with
the official 5.4 kernel carries a private patch in mm/shmem.c that rejects
"nr_inodes<2", so let's keep `nr_inodes=2` here!
Signed-off-by: lifubang <lifubang@acmcoder.com>
(cherry picked from commit feea25820e)
Signed-off-by: lifubang <lifubang@aliyun.com>
This update includes a few breaking API changes that I needed to get in
before an actual runc release depends on it, so that we don't need to
deal with compatibility shims for them (or bumping the SOVERSION).
From a Go API perspective, there were no major changes -- though this
bump did also require a bump to github.com/cyphar/filepath-securejoin
because one of the wrapped APIs changed from int to uint64 as a flag
argument type. Again, better to get this done before we really depend on
this in a public way.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
(cherry picked from commit d47bf88349)
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
go-criu v8.3.0 switches to protobuf-go-lite, which helps to remove
google.golang.org/protobuf dependency from here, reducing the runc
binary size from ~16M to ~14M.
The only missing piece is proto.String, proto.Bool, proto.Int32 etc.
helpers that return a pointer to a given variable. Those are replaced
by a generic mkPtr, which in turn is to be replaced by the new builtin
once Go < 1.26 is no longer supported.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
(cherry picked from commit f66ace4cfa)
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
As with /dev symlinks, this was missed in commit d40b3439a9 ("rootfs:
switch to fd-based handling of mountpoint targets"). It's not really
clear to what extent this was exploitable (/sys/fs/cgroup is a tmpfs we
create) but it's better to just fix this anyway.
Fixes: d40b3439a9 ("rootfs: switch to fd-based handling of mountpoint targets")
Signed-off-by: Aleksa Sarai <aleksa@amutable.com>
(cherry picked from commit 66acd48f9d)
Signed-off-by: Aleksa Sarai <aleksa@amutable.com>
These codepaths are very old and operate on pure paths but before
pivot_root(2), meaning that a bad image with a malicious /dev symlink
could cause us to operate on host paths instead.
In practice this means that we could be tricked into removing a file
called "ptmx" (note that /dev/pts/ptmx and /dev/ptmx are both immune for
different reasons) or creating a very restricted set of symlinks (with
fixed targets and names). The scope of these bugs is thus quite limited,
but we definitely need to harden against it.
These codepaths were unfortunately missed during the fd-based rework in
commit d40b3439a9 ("rootfs: switch to fd-based handling of mountpoint
targets") -- I must've assumed they were called after pivot_root(2)...
Fixes: GHSA-xjvp-4fhw-gc47
Fixes: CVE-2026-41579
Fixes: d40b3439a9 ("rootfs: switch to fd-based handling of mountpoint targets")
Signed-off-by: Aleksa Sarai <aleksa@amutable.com>
(cherry picked from commit 864db8042d)
Signed-off-by: Aleksa Sarai <aleksa@amutable.com>
This argument order matches most other helpers we have and will also
match the changes we are about to make to setupPtmx and
setupDevSymlinks.
Signed-off-by: Aleksa Sarai <aleksa@amutable.com>
(cherry picked from commit fcf04eb41b)
Signed-off-by: Aleksa Sarai <aleksa@amutable.com>
The idea of commit d1fca8e was right (report errors for non-existent
root, unless using the default root dir) but the logic was inverted.
Fix the logic.
Test case for default root requires non-existent /root/runc, which is
not always possible.
[v1.5 backport: use GlobalIsSet]
Reported-by: RedMakeUp <girafeeblue@gmail.com>
Co-authored-by: RedMakeUp <girafeeblue@gmail.com>
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
(cherry picked from commit 98c442a0e6)
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
The test checked for the exact BusyBox ash diagnostic "sh: can't fork".
With BusyBox 1.38, ash reports the failure as:
/bin/sh: line 0: can't fork: Resource temporarily unavailable
Match the stable "can't fork" part of the error message instead.
Signed-off-by: Ricardo Branco <rbranco@suse.de>
(cherry picked from commit de39d5e79b)
Signed-off-by: Ricardo Branco <rbranco@suse.de>
TestPids used long hand-written /bin/true pipelines for the 4-, 32- and
64-command cases. This made the test easy to typo and hard to review, as
seen by the earlier "bin/true" entries.
Build the shell pipelines instead, preserving the existing test coverage
while making the command counts explicit.
Signed-off-by: Ricardo Branco <rbranco@suse.de>
(cherry picked from commit 3acb097f93)
Signed-off-by: Ricardo Branco <rbranco@suse.de>
As runc binary grows in size over time (new features, more
dependencies) some tests start to flake because of low memory limits.
One such test is "runc run (cgroup v2 resources.unified override)";
it obviously fails because of 1M memory limit:
> runc run failed: unable to start container process: container init was OOM-killed (memory limit too low?)
Increase the limits 4x. Do the same for the "unified only" test.
Fixes issue 5264.
Reported-by: Kevin Berry <kpberry11@gmail.com>
Reported-by: Ricardo Branco <rbranco@suse.de>
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
(cherry picked from commit 3fabb4d070)
Signed-off-by: lifubang <lifubang@acmcoder.com>
Co-authored-by: Claude <noreply@anthropic.com>
Close the root file descriptor immediately after use in maskPaths to
reduce the window during which an attacker could potentially exploit
an open fd to access or manipulate the root filesystem. This follows
the principle of least privilege and mitigates risks in compromised
or malicious container scenarios.
Co-authored-by: Kir Kolyshkin <kolyshkin@gmail.com>
Signed-off-by: lifubang <lifubang@acmcoder.com>
(cherry picked from commit b88635e57e)
Signed-off-by: lifubang <lifubang@acmcoder.com>
This is a follow-up to #5275. That change reused a single tmpfs mount
to mask multiple directories, which is efficient when masking more than
one path. However, it introduced unnecessary overhead when only one
directory is masked. This commit restores the original behavior for the
single-path case while preserving shared tmpfs logic for multiple paths.
Signed-off-by: lifubang <lifubang@acmcoder.com>
(cherry picked from commit e7e2f00248)
Signed-off-by: lifubang <lifubang@acmcoder.com>
Kubernetes may add one sysfs thermal_throttle entry per CPU to
maskedPaths. On large Intel systems this can produce many directory
masks for a single container. runc currently handles each directory
mask with a separate read-only tmpfs mount, and therefore a separate
tmpfs superblock.
On Linux 4.18/RHEL 8 kernels, creating and tearing down many tmpfs
superblocks can contend on the global shrinker_rwsem when containers
start or stop concurrently.
Use one read-only tmpfs for directory masks and bind-mount it over the
remaining directory targets. The first non-procfs-fd directory mount is
reopened through the container root fd before it is reused. File masks
still bind /dev/null, and procfs fd targets keep the existing
one-tmpfs-per-target behaviour because they are fd aliases rather than
stable rootfs paths.
If the bind-mount of the shared source fails (e.g. due to kernel
restrictions), fall back to individual tmpfs mounts for all remaining
directories. Tmpfs mounts use nr_blocks=1,nr_inodes=1 to minimise
kernel resource usage.
The bind mounts do not create additional tmpfs superblocks. They also
retain the read-only mount flag inherited from the source vfsmount, so
the masking semantics remain unchanged.
xref: kubernetes/kubernetes#138512
xref: kubernetes/kubernetes#138388
xref: kubernetes/kubernetes#131018
Co-authored-by: Davanum Srinivas <davanum@gmail.com>
Refactored-by: lifubang <lifubang@acmcoder.com>
Signed-off-by: lifubang <lifubang@acmcoder.com>
(cherry picked from commit c046c9b973)
Signed-off-by: lifubang <lifubang@acmcoder.com>
Previously, masked directories (e.g., /proc/acpi, /proc/scsi) were
mounted as read-only tmpfs without explicit size or inode limits.
Although these mounts are meant to be empty and unwritable, the lack
of resource constraints means that—should an attacker bypass the
read-only protection (e.g., via container escape, mount namespace
manipulation, or a kernel vulnerability)—the tmpfs could consume up
to 50% of system memory by default (the kernel's default tmpfs limit).
To mitigate this risk in high-density container environments and
adhere to the principle of least privilege, we now explicitly set:
- nr_blocks=1 (sufficient for at most one block size)
- nr_inodes=1 (sufficient for at most one inode)
Ref: https://man7.org/linux/man-pages/man5/tmpfs.5.html
These limits ensure that even if compromised, kernel memory usage
remains strictly bounded and negligible.
This change aligns with best practices used by other container
runtimes and strengthens defense-in-depth for sensitive masked paths.
Co-authored-by: Davanum Srinivas <davanum@gmail.com>
Refactored-by: lifubang <lifubang@acmcoder.com>
Signed-off-by: lifubang <lifubang@acmcoder.com>
(cherry picked from commit e57a7a4c8f)
Signed-off-by: lifubang <lifubang@acmcoder.com>
Apparently, lima's experimental/fedora-rawhide image does not include
which rpm, and we don't really want to bother installing it.
Replace "which" with "command -v". Looks like this was the only place;
we already use "command -v" everywhere else.
This should fix lima (experimental/fedora-rawhide) CI.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
(cherry picked from commit 5e78f4a66d)
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
The latter is simpler and provides just enough functionality to be used
here.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
(cherry picked from commit 9970cbfdb6)
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Rodrigo Campos