Public bug reported:
Summary
After upgrading linux-raspi from 7.0.0-1020.20 to 7.0.0-1023.23
(resolute-proposed), processes inside containers run by containerd under
its default AppArmor profile can no longer signal each other. On
Kubernetes nodes (containerd + runc, the default setup of RKE2/k3s and
most distributions) this breaks ordinary workloads as soon as the node
boots the new kernel:
apparmor="DENIED" operation="signal" class="signal"
profile="cri-containerd.apparmor.d"
requested_mask="send" denied_mask="send" signal=hup
peer="cri-containerd.apparmor.d//&unconfined"
There were hundreds of such denials per boot, with signals hup, urg and
term. With 7.0.0-1020 there are none, and the userspace is identical
(apparmor 5.0.2-0ubuntu1~26.04.1).
The stacked label comes from the unprivileged-unconfined restriction. It
is already applied on 1020, where it is harmless:
apparmor="AUDIT" operation="change_onexec" info="change_profile unprivileged
unconfined converted to stacking"
profile="unconfined" name="cri-containerd.apparmor.d" comm="runc:[2:INIT]"
1023 includes "apparmor: fix unconfined user namespace restriction
forced stack" (upstream stable patchset 2026-10-05, LP: #2169638). Since
then, processes carrying the forced stack are treated as a different
peer from processes in the plain profile, so signals inside one
container are denied.
Impact
Kubernetes nodes that use containerd's default AppArmor profile are
affected. Observed on a cluster after booting 1023:
- Multi-process tools that coordinate through signals hang. For example, a
local rsync inside a container never completes, and timeout cannot terminate it.
- Daemons cannot be reloaded via SIGHUP.
- The Go runtime's SIGURG preemption signals are denied.
- Processes that cannot be terminated block clean container shutdown, pod
restarts and node reboots.
- Pods end up in restart loops (startup and liveness probes fail) and the node
degrades.
Since this lands in a stable update and unattended-upgrades installs
kernels from -security, Kubernetes clusters on 26.04 can break on the
next reboot without any configuration change.
Workaround (verified)
kernel.apparmor_restrict_unprivileged_unconfined = 0. With 7.0.0-1023 and this
setting:
- there are no signal denials and no "converted to stacking" events
- all container processes carry the plain cri-containerd.apparmor.d label
- the affected workloads behave normally again
Environment
- Ubuntu 26.04.1 LTS, arm64, linux-raspi 7.0.0-1023.23
- containerd 2.3, runc 1.4.3, apparmor 5.0.2-0ubuntu1~26.04.1
- Default sysctls (apparmor_restrict_unprivileged_userns=1,
apparmor_restrict_unprivileged_unconfined=1)
Expected
A stable kernel update should not break signal delivery inside
containers that run under the default containerd AppArmor profile.
** Affects: linux-raspi (Ubuntu)
Importance: Undecided
Status: New
** Tags: apparmor regression-proposed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2172746
Title:
7.0.0-1023 (raspi, based on 7.0.0-43): AppArmor denies signals inside
containers (forced stack //&unconfined), breaking Kubernetes nodes
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/2172746/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
