passt, branch master Plug A Simple Socket Transport tcp_splice: avoid delay on certain transfers 2026-10-14T05:48:58+00:00 Bernhard M. Wiedemann bwiedemann@suse.de 2026-10-02T16:39:25+00:00 8ba41320c3a256a3bb71b6bca641237168b5b303 without this patch, sending buffers of certain sizes caused a delay of 200ms because tcp_splice_forward() passes SPLICE_F_MORE to the writer when a read filled at least 90% of the pipe. This is easy to hit when pipes are small: once a user exceeds fs.pipe-user-pages-soft (64 MiB by default, which a few long-running pasta instances with large pipes reach on their own), tcp_set_pipe_size() settles on the 8 KiB minimum, and every message whose length is 7372 to 8192 bytes (90% of the pipe and more) past a multiple of 8 KiB stalls. This change leaves bulk throughput unchanged. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Bernhard M. Wiedemann <bwiedemann@suse.de> Signed-off-by: Stefano Brivio <sbrivio@redhat.com> 
without this patch, sending buffers of certain sizes
caused a delay of 200ms because tcp_splice_forward()
passes SPLICE_F_MORE to the writer
when a read filled at least 90% of the pipe.

This is easy to hit when pipes are small: once a user exceeds
fs.pipe-user-pages-soft (64 MiB by default, which a few long-running
pasta instances with large pipes reach on their own),
tcp_set_pipe_size() settles on the 8 KiB minimum, and every message
whose length is 7372 to 8192 bytes (90% of the pipe and more) past a
multiple of 8 KiB stalls.

This change leaves bulk throughput unchanged.

Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Bernhard M. Wiedemann <bwiedemann@suse.de>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
virtio: Limit number of mapped iovec entries to maximum available entries 2026-10-14T05:31:04+00:00 Sithum Shihara zaara98zaara@gmail.com 2026-10-10T06:33:54+00:00 265a9f96ef3cfa54d2b66ec74e60a8152c6bb0ab Based on an original patch and investigation by Sithum Shihara: limit the number of host iovec entries we use to map guest descriptors to the bound provided to virtqueue_map_desc(). If we don't, Sithum reports, on the vu_handle_tx() path, we can exceed the VIRTQUEUE_MAX_SIZE limit for the out_sg array, with some very specific configurations of memory regions. This is harmless as we could only manage to write one additional entry, 16 bytes (the size of a struct iovec), which invariably ends up into padding memory. This is however definitely not intended, and could potentially turn into robustness issues, even though we couldn't demonstrate any availability impact either, as the FORTIFY_SOURCE checks don't trigger here, because the virtqueue_map_desc() loop uses a direct assignment. We tried to achieve larger writes, which, in theory, we could try to obtain by having multiple exceeding iovec entries (not just 1), but, in practice, without modifying QEMU sources, we couldn't achieve the desired QEMU configuration and the submission of that kind of guest descriptor. However, as an abundance of caution, we considered what could happen if we had achieved that. Sticking to vu_handle_tx() as a caller, which appears to be the only interesting case, the size of the worst-case write would correspond to 30 split iovec entries, of 16 bytes each (struct iovec), that is, 480 bytes. Out of those, 256 bytes would be written to the padding area, and we would be left with 224 bytes that can overwrite up to 7 'elem' entries (and we would need to cross 16 boundaries to reach this point, which, as stated, appears unlikely to be achievable). The values written into these 'elem' array would be corrupted in a specific, predictable way, as they are the return values of vu_gpa_to_va(), but, relevantly, not of the first 8 unintended calls (because those results are written to the padding area), and, as a result, the guest can't control their values, because the 'len' parameter for the non-first calls is fixed and corresponding to the size of the memory regions. We couldn't find any writing pattern for those entries, provided a given starting 'pa' argument, that would generate a valid 'index' field as a result. The resulting values of these 7 'elem' entries can't be used as a vector to achieve arbitrary code execution either (not claimed by Sithum, and we also failed to achieve this), because they don't contain any pointer to be executed, and they can't possibly be used for heap spraying because they can't be possibly written to any heap area (passt doesn't do dynamic memory allocation). We looked into other calling paths for virtqueue_map_desc() as well, but couldn't find any way to trigger a similar out-of-bound write, because they all have external or internal bounds that prevent or limit the iovec entry overflow (to the point where we don't even reach the 'elem' array). Regardless of that, add the missing check for correctness and robustness. Ideally, we would have liked to have a rate-limited warning here, to avoid the risk of a malicious guest flooding the logs, but the call path from where we could obtain a current timestamp is rather long, and we don't expect this configuration to be actually used in any practical setup: stick to a debug() call for simplicity. We would like to thank Sithum Shihara for the precious and insightful investigation, and for sharing his results in a very clear and honest way. Reported-by: Sithum Shihara <zaara98zaara@gmail.com> Analysed-by: Sithum Shihara <zaara98zaara@gmail.com> Fixes: 7d1cd4dbf503 ("vhost-user: introduce virtio API") Signed-off-by: Stefano Brivio <sbrivio@redhat.com> 
Based on an original patch and investigation by Sithum Shihara: limit
the number of host iovec entries we use to map guest descriptors to
the bound provided to virtqueue_map_desc().

If we don't, Sithum reports, on the vu_handle_tx() path, we can exceed
the VIRTQUEUE_MAX_SIZE limit for the out_sg array, with some very
specific configurations of memory regions. This is harmless as we
could only manage to write one additional entry, 16 bytes (the size
of a struct iovec), which invariably ends up into padding memory.

This is however definitely not intended, and could potentially turn
into robustness issues, even though we couldn't demonstrate any
availability impact either, as the FORTIFY_SOURCE checks don't trigger
here, because the virtqueue_map_desc() loop uses a direct assignment.

We tried to achieve larger writes, which, in theory, we could try to
obtain by having multiple exceeding iovec entries (not just 1), but,
in practice, without modifying QEMU sources, we couldn't achieve the
desired QEMU configuration and the submission of that kind of guest
descriptor.

However, as an abundance of caution, we considered what could happen
if we had achieved that.

Sticking to vu_handle_tx() as a caller, which appears to be the only
interesting case, the size of the worst-case write would correspond
to 30 split iovec entries, of 16 bytes each (struct iovec), that is,
480 bytes.

Out of those, 256 bytes would be written to the padding area, and we
would be left with 224 bytes that can overwrite up to 7 'elem' entries
(and we would need to cross 16 boundaries to reach this point, which,
as stated, appears unlikely to be achievable).

The values written into these 'elem' array would be corrupted in a
specific, predictable way, as they are the return values of
vu_gpa_to_va(), but, relevantly, not of the first 8 unintended calls
(because those results are written to the padding area), and, as a
result, the guest can't control their values, because the 'len'
parameter for the non-first calls is fixed and corresponding to the
size of the memory regions.

We couldn't find any writing pattern for those entries, provided a
given starting 'pa' argument, that would generate a valid 'index'
field as a result.

The resulting values of these 7 'elem' entries can't be used as a
vector to achieve arbitrary code execution either (not claimed by
Sithum, and we also failed to achieve this), because they don't
contain any pointer to be executed, and they can't possibly be used
for heap spraying because they can't be possibly written to any heap
area (passt doesn't do dynamic memory allocation).

We looked into other calling paths for virtqueue_map_desc() as well,
but couldn't find any way to trigger a similar out-of-bound write,
because they all have external or internal bounds that prevent or
limit the iovec entry overflow (to the point where we don't even reach
the 'elem' array).

Regardless of that, add the missing check for correctness and
robustness. Ideally, we would have liked to have a rate-limited
warning here, to avoid the risk of a malicious guest flooding the
logs, but the call path from where we could obtain a current timestamp
is rather long, and we don't expect this configuration to be actually
used in any practical setup: stick to a debug() call for simplicity.

We would like to thank Sithum Shihara for the precious and insightful
investigation, and for sharing his results in a very clear and honest
way.

Reported-by: Sithum Shihara <zaara98zaara@gmail.com>
Analysed-by: Sithum Shihara <zaara98zaara@gmail.com>
Fixes: 7d1cd4dbf503 ("vhost-user: introduce virtio API")
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
pasta: Refactor pasta_ns_conf() to reduce nesting 2026-10-06T18:16:04+00:00 Jon Maloy jmaloy@redhat.com 2026-10-02T19:34:44+00:00 3630044b084cc94afd2d4999c0348d34e035357e Extract address and route configuration into two new helper functions pasta_conf_addrs() and pasta_conf_routes(), and replace the outer if (c->pasta_conf_ns) block with an early return. This reduces indentation and eliminates the goto labels. No functional change. Signed-off-by: Jon Maloy <jmaloy@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com> 
Extract address and route configuration into two new helper functions
pasta_conf_addrs() and pasta_conf_routes(), and replace the outer
if (c->pasta_conf_ns) block with an early return. This reduces
indentation and eliminates the goto labels.

No functional change.

Signed-off-by: Jon Maloy <jmaloy@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
tcp: Don't fast re-transmit if only our FIN is outstanding 2026-10-02T21:05:26+00:00 Aris Konstantoulas aris@ariscodes.com 2026-09-28T10:31:20+00:00 cba357068dc586e7540971eb40bb56c5e62c4de1 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 <aris@ariscodes.com> Signed-off-by: Stefano Brivio <sbrivio@redhat.com> 
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 <aris@ariscodes.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
apparmor: Fixes for new user namespace detaching procedure 2026-10-02T21:05:26+00:00 Stefano Brivio sbrivio@redhat.com 2026-10-02T13:19:58+00:00 032f082ffad094649066fa94822c5a78a246a766 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 <bts@hudrydum.cz> Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1149683 Signed-off-by: Stefano Brivio <sbrivio@redhat.com> 
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 <bts@hudrydum.cz>
Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1149683
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
util: Make setting uidmap and gidmap errors non-fatal 2026-10-02T21:04:24+00:00 Stefano Brivio sbrivio@redhat.com 2026-10-02T06:55:54+00:00 a51d395de1daca9ddd3be4d5255e867cb4d470f9 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 <yanqiyu@fedoraproject.org> Link: https://github.com/containers/crun/issues/2283 Suggested-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com> 
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 <yanqiyu@fedoraproject.org>
Link: https://github.com/containers/crun/issues/2283
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
selinux: Allow passt to use setgid and setuid capabilities in namespace 2026-10-02T20:59:58+00:00 Stefano Brivio sbrivio@redhat.com 2026-10-02T06:48:49+00:00 f86196b822a64a14ac7f4ce8307d687135a486bd 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 <sbrivio@redhat.com> 
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 <sbrivio@redhat.com>
apparmor: allow netns paths on /tmp again 2026-10-02T05:21:38+00:00 Paul Holzinger pholzing@redhat.com 2026-10-01T12:55:29+00:00 3822e7dae5cb6b87e0b3d73e8db8b5c608b9aa4b 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 <pholzing@redhat.com> [sbrivio: Replaced spaces with tabs, slightly reworded comment] Signed-off-by: Stefano Brivio <sbrivio@redhat.com> 
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 <pholzing@redhat.com>
[sbrivio: Replaced spaces with tabs, slightly reworded comment]
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
udp: Add missing @now parameter doc to udp_flow_from_tap() 2026-09-25T21:03:06+00:00 Laurent Vivier lvivier@redhat.com 2026-09-23T14:26:31+00:00 df90211db4b08a06ed4e499ffa40bf8811100a2f udp_flow_from_tap() takes a @now parameter but its doc comment omits it. Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Stefano Brivio <sbrivio@redhat.com> 
udp_flow_from_tap() takes a @now parameter but its doc comment
omits it.

Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
apparmor: Use user-tmp abstraction, allow /var/tmp instead of /tmp only 2026-09-25T20:38:51+00:00 Stefano Brivio sbrivio@redhat.com 2026-09-25T20:38:51+00:00 f2683d14802d1430b383f48eb3105f11361edda1 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 <gscrivan@redhat.com> Link: https://github.com/podman-container-tools/container-libs/pull/1207 Signed-off-by: Stefano Brivio <sbrivio@redhat.com> 
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 <gscrivan@redhat.com>
Link: https://github.com/podman-container-tools/container-libs/pull/1207
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>