Debian Patches

Status for criu/4.2-4

Patch Description Author Forwarded Bugs Origin Last update
tty-fix-compiler-error.patch tty: fix compiler error
At least on tests running on Fedora rawhide following error could be
seen:

```
criu/tty.c: In function 'pts_fd_get_index':
criu/tty.c:262:21: error: initialization discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
262 | char *pos = strrchr(link->name, '/');
|
```

This fixes it.		 Adrian Reber <areber@redhat.com> no debian https://github.com/checkpoint-restore/criu/commit/90300748effc1cf0fe56e35d3d1cc2ddfedab246 2025-11-26
pagemap-cache-stop-filling-cache-on-VMA_AREA_GUARD.patch pagemap-cache: stop filling cache on VMA_AREA_GUARD
VMA_AREA_GUARD areas are added to the end of the vma_area_list and
are not necessarily sorted by address. pmc_fill_cache() expects
VMAs to be sorted and triggers BUG_ON() if it meets a VMA with
a lower address than the current cache window.

Since guard VMAs don't have pagemap entries and are skipped during
dump, just stop the lookahead loop when we encounter one.		 Andrei Vagin <avagin@gmail.com> no debian https://github.com/checkpoint-restore/criu/commit/f5974cc326c19d294956372067c28d160a1d29c5 2026-03-04
scripts-rseq-fix-detection-of-rseq_cpu_id_state.patch scripts: rseq: fix detection of rseq_cpu_id_state
gcc doesn't report any warnings if there are two identical enums with the
same name. Actually, we wanted to detect if a specific enum is already
exists. By using a different member name in the test, we ensure that a
conflict occurs if the enum is already defined in the system headers.		 Andrei Vagin <avagin@gmail.com> no debian https://github.com/checkpoint-restore/criu/commit/3f3acc3200a23140abaa32a2017ae159d3c2d02c 2026-03-03
zdtm-Fix-rseq01-test-for-kernel-7.0-rseq-changes.patch zdtm: Fix rseq01 test for kernel 7.0 rseq changes
Starting with Linux 7.0, the rseq feature size has grown to 33 bytes
and AT_RSEQ_ALIGN has increased to 64. This causes sizeof(struct rseq)
from the uapi header to be 64 (33 bytes padded to aligned(32)), while
the actual registration size used by glibc (__rseq_size) is 33.

The rseq01 test was using sizeof(struct rseq) as the registration
size and a test-local __rseq_abi variable (with only 32-byte
alignment from the uapi header) as the rseq area. Both are
wrong on kernel 7.0:

- The kernel now checks alignment against __alignof__(struct rseq)
which is 64 internally; the 32-byte-aligned test variable may
not satisfy this.

- sizeof(struct rseq) = 64 does not match the feature size of 33
that glibc registered with, so re-registration with a different
size fails.

Fix by:

- Using __rseq_size (the feature size reported by glibc) as the
registration size instead of sizeof(struct rseq).

- Using the glibc-provided rseq area (at thread_pointer() +
__rseq_offset) which is allocated with proper AT_RSEQ_ALIGN
alignment, instead of a test-local variable.

Both fall back to the previous behavior when glibc rseq support
is not available.

This mirrors the glibc fix:

https://sourceware.org/cgit/glibc/commit/?id=67f303b47dc584f204e3f2441b9832082415eebc		 Adrian Reber <areber@redhat.com> no https://github.com/checkpoint-restore/criu/commit/5546c06a125dac3c9df2401ae52cebda526c2a27 2026-04-21
net-Route-veth-restore-through-usernsd-for-userns-mo.patch net: Route veth restore through usernsd for userns mode
Starting with Linux kernel commit 7b735ef81286 ("rtnetlink: add
missing netlink_ns_capable() check for peer netns"), creating a
veth pair with a peer in a different network namespace requires
CAP_NET_ADMIN in the peer namespace as well:

rtnetlink: add missing netlink_ns_capable() check for peer netns

rtnl_newlink() lacks a CAP_NET_ADMIN capability check on the peer
network namespace when creating paired devices (veth, vxcan,
netkit). This allows an unprivileged user with a user namespace
to create interfaces in arbitrary network namespaces, including
init_net.

Add a netlink_ns_capable() check for CAP_NET_ADMIN in the peer
namespace before allowing device creation to proceed.


When CRIU restores a veth in user namespace mode, it sends the
RTM_NEWLINK request from a netlink socket inside the child user
namespace. The veth peer is placed into the root network namespace
via IFLA_NET_NS_FD, but the child user namespace does not have
CAP_NET_ADMIN in the root namespace, so the new kernel check
rejects the request with EPERM.

Fix this by routing the veth creation through usernsd when the
peer lives in an external (host) namespace specified via the
--external veth[name] restore option. usernsd runs with real
root privileges in the init user namespace, so it passes the
capability check in both namespaces.

The usernsd path is only used for external veth mappings, not for
child-to-child namespace veths (has_peer_nsid), because in that
case both namespaces share the same user namespace and already
have CAP_NET_ADMIN in each other.

The approach mirrors restore_one_macvlan(), which already solves
the same CAP_NET_ADMIN-in-both-namespaces problem for macvlan
devices. A new veth_link_info_userns() builds the RTM_NEWLINK
request without IFLA_NET_NS_FD for the peer -- since usernsd
sends the request from the root network namespace, the peer
naturally stays there. userns_restore_one_link() then adds a
top-level IFLA_NET_NS_FD to move the main device into the child
namespace.		 Adrian Reber <areber@redhat.com> no https://github.com/checkpoint-restore/criu/commit/14cb3c201634560fd267aec5bb6217e91aaf46d2 2026-04-21

All known versions for source package 'criu'

Links