passt, branch 2026_10_02.cba3570

tcp: Don't fast re-transmit if only our FIN is outstanding

2026-10-02T21:05:26+00:00

In the TAP_FIN_RCVD path of tcp_tap_handler(), a bare segment from the
guest acknowledging exactly seq_ack_from_tap, with an unchanged window,
is taken as a duplicate ACK and triggers a fast re-transmit.

If the only unacknowledged sequence number is our own FIN, that's
harmful: tcp_rewind_seq() rewinds seq_to_tap and clears TAP_FIN_SENT,
so tcp_data_from_sock() immediately sends the FIN again. If the guest
answers that FIN with the same bare ACK, as a socket in TIME-WAIT will,
we loop at packet rate:

- conn->retries is never incremented on this path, so we never reach
  TCP_MAX_RETRIES and tcp_rst()

- ACK_FROM_TAP_DUE is re-armed on every iteration, so the backed-off
  re-transmission in tcp_timer_handler() never fires

- TAP_FIN_ACKED can't be set, as it requires TAP_FIN_SENT, which the
  rewind just cleared

On an idle Podman host (rootless, pasta), this showed up as a single
flow exchanging ~45,000 54-byte segments per second between pasta and
a container whose socket was in TIME-WAIT, with pasta using ~75% of one
core, until the socket was killed by hand. It recurred on the idle
teardown of an HTTP/2 connection to an ACME server.

With a raw-socket peer driving the same sequence against pasta at
f8df3f1, pasta re-sent the FIN 727,509 times in 10 seconds. With this
change it's re-transmitted by the timer at 1, 3, 7, 15, 31, 63 and 127
seconds, and the connection is reset once TCP_MAX_RETRIES is reached.

Don't consider a duplicate ACK as a fast re-transmit trigger if the
only outstanding sequence number is the FIN, and leave it to the timer.
Fast re-transmit of data is unaffected, with or without a FIN queued
after it.

Fixes: bde1847960cf ("tcp: Fast re-transmit if half-closed, make TAP_FIN_RCVD path consistent")
Link: https://bugs.passt.top/show_bug.cgi?id=125
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Aris Konstantoulas 
Signed-off-by: Stefano Brivio

apparmor: Fixes for new user namespace detaching procedure

2026-10-02T21:05:26+00:00

Commit 7bf1595c9242 ("isolation: Don't create our userns as nobody")
changed the procedure user namespaces are detached, also for passt,
and adds unconditional setting of UID and GID maps.

This needs AppArmor adjustments:

- rules to access gid_map, uid_map, and setgroups entries in procfs
  now need to be enabled for passt as well, not just for pasta: move
  them to the passt abstraction (which is included from the pasta
  abstraction)

- we now need to open a user namespace originally detached by a
  separate holder process, which requires us to open procfs entries
  that are disconnected (from an AppArmor perspective) from the
  original namespace: add the attach_disconnected flag to the profile
  for passt as well (this was already the case for pasta).

  This isn't ideal but there doesn't seem any way around it: opening
  the namespace from the holder process itself doesn't help either.

  We'll need to add this flag also in passt subprofiles for
  guestfs-tools (maintained in Debian) and libvirtd (which only
  applies when guests are started as root for the moment, maintained
  by libvirt upstream).

Reported-by: Michal Humpula 
Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1149683
Signed-off-by: Stefano Brivio

util: Make setting uidmap and gidmap errors non-fatal

2026-10-02T21:04:24+00:00

Starting from commit 7bf1595c9242 ("isolation: Don't create our userns
as nobody"), we unconditionally set uidmap and gidmap in the detached
user namespace.

If passt is started from a detached PID namespace, but /proc hasn't
been remounted to reflect this, we'll fail to write those entries.

That's actually fine as uidmap and gidmap are something that, strictly
speaking, we only need to write in pasta mode when a command is
detached (it's now done in all cases for simplicity).

Warn, because it's not the expected behaviour (/proc should probably
be remounted first), but don't fail on that.

Reported-by: Qiyu Yan 
Link: https://github.com/containers/crun/issues/2283
Suggested-by: David Gibson 
Signed-off-by: Stefano Brivio

selinux: Allow passt to use setgid and setuid capabilities in namespace

2026-10-02T20:59:58+00:00

Starting from commit 7bf1595c9242 ("isolation: Don't create our userns
as nobody"), we unconditionally set uidmap and gidmap in the detached
user namespace.

Allow that in SELinux rules. We also need to allow explicit access to
the related files.

While at it, add the matching class requirements in pasta.te, which I
forgot (harmless as they were indirectly required, but not really
correct).

Link: https://bodhi.fedoraproject.org/updates/FEDORA-2026-3a8fb909da#comment-4790590
Fixes: 71b74e924426 ("isolation: Don't create our userns as nobody")
Signed-off-by: Stefano Brivio

apparmor: allow netns paths on /tmp again

2026-10-02T05:21:38+00:00

The change to the user-tmp abstraction broke pasta as it can no longer
open the netns path given by podman when it is under /tmp.

The abstraction uses "owner" while the kernel always seems to report
ouid=0 for the bind mounted netns reference. I originally fixed that
in commit 6cdc9fd51bf6 ("apparmor: allow netns paths on /tmp").

In order to fix the regression add /tmp explicitly again here while
keeping the abstraction to still allow /var/tmp for the other regular
files.

Link: https://github.com/podman-container-tools/podman/pull/29867#pullrequestreview-5378330040
Fixes: f2683d14802d ("apparmor: Use user-tmp abstraction, allow /var/tmp instead of /tmp only")
Signed-off-by: Paul Holzinger 
[sbrivio: Replaced spaces with tabs, slightly reworded comment]
Signed-off-by: Stefano Brivio

udp: Add missing @now parameter doc to udp_flow_from_tap()

2026-09-25T21:03:06+00:00

udp_flow_from_tap() takes a @now parameter but its doc comment
omits it.

Signed-off-by: Laurent Vivier 
Signed-off-by: Stefano Brivio

apparmor: Use user-tmp abstraction, allow /var/tmp instead of /tmp only

2026-09-25T20:38:51+00:00

Podman overrides TMPDIR to /var/tmp, and an upcoming change in the
requires pasta to write its PID file to TMPDIR.

To support this in the AppArmor policy, we need to loosen the existing
rule restricting file writes to /tmp/ and subpaths in order to include
common alternative paths for TMPDIR: the user-tmp abstraction does
exactly this.

Reported-by: Giuseppe Scrivano 
Link: https://github.com/podman-container-tools/container-libs/pull/1207
Signed-off-by: Stefano Brivio

pasta: Add --no-pidns to keep spawned command in caller's PID namespace

2026-09-16T08:54:02+00:00

This is to allow running pasta inside a container without unmasking
/proc for the whole container (Docker's --security-opt
systempaths=unconfined, Podman's --security-opt unmask=ALL), which is
undesirable as it exposes /proc/sysrq-trigger and other masked paths.

In spawn mode, pasta clones the command with CLONE_NEWPID and mounts a
new procfs instance on /proc, so that it matches the new PID namespace.

Mounting procfs in a new user namespace requires a fully visible,
unobstructed procfs. Container runtimes deliberately obstruct /proc
(Docker, for example, masks /proc/kcore and friends and mounts
/proc/sys read-only), so the mount is refused:

  Couldn't mount /proc: Operation not permitted

We only warn and continue, leaving the command in a new PID namespace
while the visible /proc still numbers processes in the outer one.
Anything resolving its own PID through /proc then fails, for example
bubblewrap:

  bwrap: open /proc/22/ns/ns failed: No such file or directory

Add a --no-pidns option: skip CLONE_NEWPID for the spawned command and
don't mount /proc, which is then not needed. User, network, mount, UTS
and IPC namespaces, --config-net and port forwarding are unaffected.
The option is rejected together with PID or --netns, as it only makes
sense when we spawn the command ourselves.

Add a test checking that, by default, the command runs in a new PID
namespace, and that --no-pidns keeps it in the caller's one.

Signed-off-by: Christian Korneck 
Signed-off-by: Stefano Brivio

contrib/apparmor: add missing setfcap capability

2026-09-08T14:15:39+00:00

Since Linux 5.12, writing a mapping from UID 0 to /proc/self/uid_map
requires CAP_SETFCAP. isolation.c already retains this capability for
the case where pasta spawns a child from a non-init user namespace,
but the AppArmor profile doesn't grant it, so the write is denied
whenever the profile is enforced.

Add setfcap to the AppArmor abstraction to match what isolation.c
expects.

Link: https://bugs.passt.top/show_bug.cgi?id=172
Signed-off-by: Sevinj Aghayeva 
Signed-off-by: Stefano Brivio

vhost_user: Reset vq enable flag in vu_cleanup()

2026-09-08T14:15:37+00:00

vu_cleanup() resets most virtqueue state (started, notification,
file descriptors) but does not reset the enable flag.  After a
QEMU disconnect and reconnect, the stale enable flag causes
vu_set_vring_enable_exec() to hit its early return check
(vq->enable == enable).

Reset vq->enable to false in vu_cleanup() alongside the other
virtqueue state.

Signed-off-by: Laurent Vivier 
Reviewed-by: David Gibson 
Signed-off-by: Stefano Brivio