passt, branch master

main: Ensure fds 0-2 are populated

2026-07-18T07:54:37+00:00

Usually fds 0-2 are stdin, stdout and stderr.  However, there are certain
use cases where passt can be invoked with one or more of those standard fds
closed.  In those cases, anything we open might be placed in one of the
standard slots.  For the handful of things we open early enough, this can
be a problem because we close fds 0-2 in __daemon(), replacing them with
dupes of /dev/null.

We could avoid closing those fds in __daemon() if they're not standard
streams.  However, leaving things other than the standard streams in fds
0-2 is a footgun: a stray printf() that occurs in a circumstance it
shouldn't could send harmful garbage to a device or socket.  It's also
likely to be confusing if debugging with strace or similar.

To avoid this, fill any missing standard streams with a dupe of /dev/null,
right after isolate_fds().  Since open()ing /dev/null itself could land in
one of those fd 0-2 slots, we need to be careful when we close it not to
leave a new gap.

Link: https://bugs.passt.top/show_bug.cgi?id=215
Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

isolation: Move --fd descriptor to a number of our choosing

2026-07-18T07:54:31+00:00

Some users of passt pass an fd for the tap interface in, with the --fd
parameter, rather than having passt open it itself.  This requires some
slightly fiddly logic in isolate_fds() so we don't close() it along with
any other file descriptors leaked into us by the parent.

More importantly, this is broken if the passed fd is 0, 1 or 2, since in
that case we will assume it's a standard stream and close it in __daemon().
We explicitly disallow 1 or 2 in conf_tap_fd(), but 0 has been permitted
since aa1cc8922 ("conf: allow --fd 0").  It looks like the use case of the
contributor of that patch didn't involve daemonizing passt.

To fix this more robustly, use dup2() to move to the passed fd to 3.  This
removes the possibility of mixing it up with a standard stream, and as a
bonus makes the close_range() logic much simpler.  With isolate_fds() made
safe for --fd 1 and --fd 2, we can remove the logic excluding those from
conf_fd_tap().

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

conf: Make conf_tap_fd() operate more like conf_mode()

2026-07-18T07:54:29+00:00

We have two cases where we need to parse specific options early:
conf_tap_fd() and conf_mode().  conf_tap_fd() has a slightly odd interface,
requiring the caller to use getopt_long() to find the right option, then
pass it in.  Alter it to work like conf_mode() instead, where all the
command line parsing logic is contained within the conf.c function.

This is slightly more lines, but has a clearer division of responsibility.

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

isolation, conf: Set c->fd_tap from early parse of --fd

2026-07-18T07:54:27+00:00

We parse --fd twice: once in isolate_initial() just to avoid clobbering
the passed in fd.  Then we parse it "for real" in conf(), to set c->fd_tap
and other configuration variables.

Change this, so that we return the value parsed early from
isolate_initial() and set c->fd_tap from that.  This doesn't accomplish
much immediately, but will make some further cleanups possible.

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

isolation: Move close_open_files() to isolate_fds()

2026-07-18T07:54:24+00:00

Most functions in util.c are, well, utilities, that are useful in a bunch
of places.  close_open_files(), however, is very specific, it's only called
from isolate_initial(), and performs a very specific step of our self
isolation.  So, it makes more sense as a function in isolate.c - move it
there and rename it to isolate_fds().

In addition, call it directly from main() rather than from
isolate_initial().  That's pretty arbitrary now, but will make some
subsequent changes easier.

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

passt: Always close pidfile_fd, not just when daemonizing

2026-07-18T07:53:47+00:00

In order to satisfy static checkers that we don't have an fd leak,
a9c61ffaf153 added a close() of c->pidfile_fd, amongst others.  However,
it only close()s it in the case where we daemonize into the background.
While less universally useful in the foreground / non-daemon case, it's
perfectly reasonable to still have a pidfile.  We'll still write it, and
we should still close it.

Fixes: a9c61ffaf153 ("util, passt: Close daemon-lifetime fds on exit to avoid Coverity warning")
Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

tap: Fix EAGAIN/EWOULDBLOCK check in tap_pasta_input()

2026-07-17T10:39:12+00:00

On Linux, EAGAIN and EWOULDBLOCK have the same value. Commit
d2a1dc744b10 ("tap: Restructure in tap_pasta_input()") added a check for
EWOULDBLOCK on purpose:

> - Check for EWOULDBLOCK as well as EAGAIN for the benefit of any future
>   ports where those might not have the same value

However, the condition uses && instead of ||, so it can never be true on a
platform where EAGAIN and EWOULDBLOCK are different.

Use || instead so that the check works as intended on such platforms.

Fixes: d2a1dc744b10 ("tap: Restructure in tap_pasta_input()")
Signed-off-by: Hayato Kiwata 
Reviewed-by: David Gibson 
Signed-off-by: Stefano Brivio

passt.1, pesto.1: ::1 is an address, not a port

2026-07-16T08:47:00+00:00

Fixes: 4e09ddf03443 ("conf: Allow user-specified auto-scanned port forwarding ranges")
Fixes: cbd58d631db9 ("pesto: Parse and add new rules from command line")
Signed-off-by: Stefano Brivio 
Reviewed-by: David Gibson

dhcp: Make option parsing more robust, explicitly handle options 0 and 255

2026-07-16T08:46:22+00:00

The initial option-scanning loop in dhcp(), so far, ignored options 0
(Pad Option, RFC 2132, Section 3.1) and 255 (End Option, RFC 2132,
Section 3.2).

As a result:

- if we ever encountered option 0 in the middle of option fields
  (never seen in practice), we would potentially terminate the loop
  too early, before scanning remaining options

- a malformed message with an option 255 followed by a length byte
  would (reliably) cause us to terminate as we would exceed the
  allocated size for the 'opts' array, which is detected as buffer
  overflow by the FORTIFY_SOURCE mechanism

The latter was reported as potential vulnerability by AISLE, but it's
not actually a vulnerability as we always terminate without carrying
on further handling, and in our security model the guest is able to
sabotage its own connectivity in any case (for example, a malformed
frame from the hypervisor would cause us to reset the connection, or
entirely flooding the flow table would cause inbound connectivity to
stop working, etc.).

The reported behaviour, however, is indeed a defect, as it affects
the functional robustness to a hypothetical issue in a DHCP client,
and that's something we definitely want to fix.

Make the option parsing loop more robust by:

- resizing 'opts' from 255 to 256 elements: there's no particular
  reason to try to save a tiny bit of memory (which shouldn't even
  be allocated in practice) instead of being defensive about it

- explicitly handle options 0 (skip one byte, continue) and 255 (stop
  processing options) in the option-scanning loop

- scanning the last two bytes of options as well and using
  iov_tail_size(data) directly as loop condition, instead of a rather
  inconsistent usage of opt_len

This bug was found and an initial version of the patch was written by
the AISLE AI security scanning tool (https://aisle.com/platform).

Reported-by: AISLE
Signed-off-by: Stefano Brivio 
Reviewed-by: David Gibson

CONTRIBUTING.md: The tag is "Link:", regardless of how many we have

2026-07-16T07:17:02+00:00

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