- dev - passt

[PATCH v6 0/6] Add --dhcp-boot and --dhcp-opt options
by Anshu Kumari 24 Aug '26

24 Aug '26

This series adds support for custom DHCP options in passt, enabling network boot (PXE/UEFI HTTP Boot) and arbitrary DHCP option injection. Two new command-line flags are introduced: --dhcp-boot URL Sets the boot file URL (DHCP option 67 and the legacy boot file field) --dhcp-opt CODE,VALUE Sets any DHCP option by numeric code, with type-aware parsing per RFC 2132 The DHCP reply path is extended with option overload support (RFC 2132 option 52), allowing options to overflow into the file and sname fields when the standard options area is full. RFC 3396 option splitting for concatenation-requiring options has also been introduce as a separate patch. Anshu Kumari (6): dhcp: Refactor fill_one() to operate on a generic buffer dhcp: Add option state management with enum opt_state dhcp: Add option overload dhcp: Add --dhcp-opt with option table and value parser dhcp: Add --dhcp-boot command-line option dhcp: Add RFC 3396 option splitting for concatenation-requiring options conf.c | 31 +++- dhcp.c | 561 ++++++++++++++++++++++++++++++++++++++++++++++++++------ dhcp.h | 2 + passt.1 | 49 +++++ 4 files changed, 588 insertions(+), 55 deletions(-) -- 2.55.0

1 6

[PATCH v3 0/2] [PATCH 0/2] dhcpv6: Add --dhcpv6-opt for custom DHCPv6 options
by Anshu Kumari 24 Aug '26

24 Aug '26

This series adds a --dhcpv6-opt CODE,VALUE command-line option to inject custom options into DHCPv6 replies, complementing the existing --dhcp-opt support for DHCPv4. The primary use case is UEFI HTTP Boot, which requires Vendor Class (option 16) with the correct enterprise-number + length-prefixed wire encoding per RFC 8415 Section 21.16, and Boot File URL (option 59). Value formats are determined automatically from the option code via a type table. Supported types include plain strings, IPv6 addresses (single and list), 8/16/32-bit integers, vendor class (ENTERPRISE:DATA), and length-prefixed string lists. Anshu Kumari (2): dhcpv6: Add --dhcpv6-opt with option type table and value parser dhcpv6: Inject custom options into DHCPv6 replies conf.c | 25 +++- dhcpv6.c | 363 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ dhcpv6.h | 2 + passt.1 | 31 +++++ 4 files changed, 420 insertions(+), 1 deletion(-) -- 2.55.0

1 2

[PATCH] netlink: Don't warn about multiple interfaces when there's only one
by Hayato Kiwata 22 Aug '26

22 Aug '26

Suppose there is a single network interface on the host, with two addresses of different prefixes assigned to it. In this situation, running pasta to create an isolated netns prints "Multiple interfaces with %s routes, picked first", even though there is in fact only one candidate interface. Reproducer: sudo ip link add dummy42 type dummy sudo ip link set dev dummy42 up sudo ip addr add fdaa:aaaa:aaaa::1/64 dev dummy42 sudo ip addr add fdbb:bbbb:bbbb::1/64 dev dummy42 pasta --config-net -- true This message is meant to indicate that there are multiple candidate interfaces, but in fact there is only one, which can mislead users. Therefore, avoid printing this message when there are multiple non-default routes that all belong to the same interface. Fixes: 450a6131beab ("netlink: With no default route, pick the first interface with a route") Signed-off-by: Hayato Kiwata <dev(a)haytok.jp> --- netlink.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/netlink.c b/netlink.c index 8d20dbb..225b666 100644 --- a/netlink.c +++ b/netlink.c @@ -271,6 +271,7 @@ unsigned int nl_get_ext_if(int s, sa_family_t af) }; unsigned defifi = 0, anyifi = 0; unsigned ndef = 0, nany = 0; + bool multi_anyif = false; struct nlmsghdr *nh; struct rtattr *rta; char buf[NLBUFSIZ]; @@ -330,6 +331,8 @@ unsigned int nl_get_ext_if(int s, sa_family_t af) nany++; if (!anyifi) anyifi = thisifi; + else if (anyifi != thisifi) + multi_anyif = true; } } @@ -345,7 +348,7 @@ unsigned int nl_get_ext_if(int s, sa_family_t af) } if (anyifi) { - if (nany > 1) { + if (multi_anyif) { info("Multiple interfaces with %s routes, picked first", af_name(af)); } -- 2.39.5 (Apple Git-154)

1 0

[PATCH 0/5] Settings for Zed editor and minor fixups
by David Gibson 21 Aug '26

21 Aug '26

I've been playing with the Zed editor again. It's default settings don't quite match passt's style, so add a config file to make it do the right thing. Also update some of the config for clangd to suppress bogus warnings the way Zed invokes it. Between them these also found a handful of minor but real code warts, so fix those, too. David Gibson (5): clangd: Add _GNU_SOURCE to default clangd options util: Eliminate a stray trailing whitespace util: Add missing O_CLOEXEC for !HAS_GETRANDOM path util, pasta: Remove some unneeded #includes Add Zed editor settings .clangd | 2 +- .zed/settings.json | 4 ++++ pasta.c | 1 - util.c | 7 ++----- 4 files changed, 7 insertions(+), 7 deletions(-) create mode 100644 .zed/settings.json -- 2.53.0

2 5

[PATCH 3/5] util: Add missing O_CLOEXEC for !HAS_GETRANDOM path
by David Gibson 21 Aug '26

21 Aug '26

It rarely matters, since we usually have getrandom(), but in case we don't our open() of /dev/random was missing O_CLOEXEC, which can cause clang warnings. Signed-off-by: David Gibson <david(a)gibson.dropbear.id.au> --- util.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/util.c b/util.c index 500e8f55..df972a05 100644 --- a/util.c +++ b/util.c @@ -964,7 +964,7 @@ void raw_random(void *buf, size_t buflen) { size_t random_read = 0; #ifndef HAS_GETRANDOM - int fd = open(DEV_RANDOM, O_RDONLY); + int fd = open(DEV_RANDOM, O_RDONLY | O_CLOEXEC); if (fd < 0) die_perror("Couldn't open %s", DEV_RANDOM); -- 2.53.0

2 1

[PATCH 2/5] util: Eliminate a stray trailing whitespace
by David Gibson 21 Aug '26

21 Aug '26

We generally avoid trailing whitespace, but one slipped in. Fix it. Signed-off-by: David Gibson <david(a)gibson.dropbear.id.au> --- util.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/util.c b/util.c index 28c32e43..500e8f55 100644 --- a/util.c +++ b/util.c @@ -1072,7 +1072,7 @@ void passt_exit(int status) /* Make sure we don't leave any messages incomplete */ (void)fflush(stderr); (void)fflush(stdout); - + _exit(status); } -- 2.53.0

2 1

[PATCH] RFC: Don't override system's default ping_group_range for pasta
by David Gibson 20 Aug '26

20 Aug '26

When spawning a command, pasta sets the net.ipv4.ping_group_range sysctl to 0 0, meaning only group 0 can use ping sockets within the namespace. Since group 0 is the only one we map in the userns, that's equivalent to anyone being able to use ping sockets. Although the kernel default for this is 1 0 (nobody can use ping sockets), common distros - at least ones using systemd or even just systemd-udevd - appear to set it to "0 2147483647" meaning effectively anyone can use ping sockets. There's no obvious reason that we need to override the system's default behaviour here. The override was introduced in 32d07f5e5 ("passt, pasta: Completely avoid dynamic memory allocation") as part of a large chunk which kind of looks like it was meant to be in another patch, so the git history isn't particularly informative. Signed-off-by: David Gibson <david(a)gibson.dropbear.id.au> --- pasta.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/pasta.c b/pasta.c index 5aa56b78..4248b508 100644 --- a/pasta.c +++ b/pasta.c @@ -198,9 +198,6 @@ static int pasta_spawn_cmd(void *arg) if (mount("", "/proc", "proc", 0, NULL)) warn_perror("Couldn't mount /proc"); - if (write_file("/proc/sys/net/ipv4/ping_group_range", "0 0")) - warn("Cannot set ping_group_range, ICMP requests might fail"); - a = (const struct pasta_spawn_cmd_arg *)arg; conf_hostname_len = strlen(a->c->hostname); -- 2.55.0

1 0

[PATCH 0/1] Leftover parsing patch
by David Gibson 19 Aug '26

19 Aug '26

I'm not sure if this patch is particularly useful, however it was already complete, left over from the earlier parsing rework. So, I thought I might as well post it in case it's interesting. David Gibson (1): parse: Convert parse_mac() to conventions of parse.c Makefile | 1 + conf.c | 43 ++++++++----------------------------------- parse.c | 30 ++++++++++++++++++++++++++++++ parse.h | 1 + 4 files changed, 40 insertions(+), 35 deletions(-) -- 2.55.0

1 1

[PATCH 0/5] Add AFL++ fuzzing support for passt
by Anshu Kumari 18 Aug '26

18 Aug '26

This series adds integrated AFL++ fuzzing support for passt, extending the earlier work by AbdAlRahman Gad with persistent mode, bidirectional protocol fuzzing, and real TCP connection coverage via a companion test server. Architecture ------------ The fuzzer runs passt in AFL++ persistent mode (__AFL_LOOP) with shared memory fuzzing. A separate test server process connects to passt's UNIX socket and listens on 127.0.0.1:9999 for real TCP connections: Deterministic wrappers replace clock_gettime, getrandom, getsockopt, and recv-family calls to eliminate kernel-level non-determinism. Per-iteration reset of the flow table, epoll instance, and clock. *** BLURB HERE *** Anshu Kumari (5): fuzz: Add deterministic wrappers for system calls fuzz: Add flow type guards for fuzzing stability fuzz: Bypass isolation and adapt sockets for AFL++ fuzz: Add AFL++ persistent mode fuzz loop fuzz: Add test server for bidirectional protocol fuzzing Makefile | 28 +- fuzz-server.c | 490 +++++++++++++++++++++++++++++++++ fuzz.c | 275 ++++++++++++++++++ fuzz.h | 62 +++++ fuzzing/README.fuzzing.md | 95 +++++++ fuzzing/testcase_dir/empty.bin | Bin 0 -> 12 bytes icmp.c | 14 +- isolation.c | 11 + passt.c | 189 +++++++++++++ passt.h | 4 + tap.c | 21 ++ tcp.c | 19 +- tcp_buf.c | 1 + tcp_splice.c | 10 + udp.c | 29 +- udp_flow.c | 5 + util.c | 10 + 17 files changed, 1251 insertions(+), 12 deletions(-) create mode 100644 fuzz-server.c create mode 100644 fuzz.c create mode 100644 fuzz.h create mode 100644 fuzzing/README.fuzzing.md create mode 100644 fuzzing/testcase_dir/empty.bin -- 2.55.0

3 22

[PATCH] udp_flow: Remove obsolete comment
by David Gibson 18 Aug '26

18 Aug '26

This comment was true - although the upshot was not particularly clear - when it was introduced. However, for other reaosns we now *do* always populate ini->oaddr from flow_initiate_sa(). So rather than explaning why we can't, we can actually validate ini->oaddr. Signed-off-by: David Gibson <david(a)gibson.dropbear.id.au> --- udp_flow.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/udp_flow.c b/udp_flow.c index f59649f6..a29f3562 100644 --- a/udp_flow.c +++ b/udp_flow.c @@ -247,11 +247,8 @@ flow_sidx_t udp_flow_from_sock(const struct ctx *c, uint8_t pif, ini = flow_initiate_sa(flow, pif, s_in, dst, port); if (!inany_is_unicast(&ini->eaddr) || + inany_is_unspecified(&ini->oaddr) || ini->eport == 0 || ini->oport == 0) { - /* In principle ini->oddr also must be specified, but when we've - * been initiated from a socket bound to 0.0.0.0 or ::, we don't - * know our address, so we have to leave it unpopulated. - */ flow_err_ratelimit(flow, now, "Invalid endpoint on UDP recvfrom()"); flow_alloc_cancel(flow); -- 2.55.0

1 0