# fastd v23

This release contains a number of small improvements and bugfixes, including mitigations for the LOW severity vulnerability `CVE-2025-24356`.

## Bugfixes

- Add mitigations for fast-reconnect amplification attacks

  When receiving a data packet from an unknown IP address/port combination, fastd will assume that one of its connected peers has moved to a new address (for example due to internet lines with dynamic IP, or roaming between WWAN and a local internet connection) and initiate a reconnect by sending a handshake packet. This “fast reconnect” avoids having to wait for a session timeout (up to ~90s) until a new connection is established.

  Even a 1-byte UDP packet just containing the fastd packet type header can trigger a much larger handshake packet (~150 bytes of UDP payload). With fastd v22, this number is doubled, because two handshakes are sent (one in a pre-v22-compatible format and one in a new L2TP-style format). Including IPv4 and UDP headers, the resulting amplification factor is roughly 12-13.

  By sending data packets with a spoofed source address to fastd instances reachable on the internet, this amplification of UDP traffic might be used to facilitate a Distributed Denial of Service attack.

  fastd has always implemented rate limiting for handshakes to unknown IP addresses and ports to 1 handshake per 15s to avoid this kind of attack, however the rate is limited per-port and not per-address, thus still allowing handshakes to be sent to all 65535 UDP ports of the same IP address unlimited.

  The issue has been mitigated in fastd v23 by a number of changes:

  - Rate-limiting has been changed changed to be applied per-address instead of per-port

  - Only one handshake instead of two handshakes is sent for fast-reconnect (by determining from the format of the data packet whether a pre-v22 or L2TP-style handshake should be used)

  - Require at least a full method header instead of just a single byte for a data packet to be considered valid. This does not have an effect on instances that enable the `null` method (regardless of `null` being actually in use), as a single-byte UDP packet is a valid `null` keepalive, but for all other methods the amplification factor is slightly reduced.

  Only fastd instances that allow connections from arbitrary IP addresses are vulnerable. Instances in a “client” role that configure their peers using the `remote` config option (which includes the common deployment as part of the Gluon wireless mesh firmware) will not respond to unexpected data packets with a handshake and are therefore unaffected.

  `CVE-2025-24356` has been assigned to this issue. The severity of this vulnerability is considered LOW.

  A GitHub security advisory can be found under GHSA-pggg-vpfv-4rcv.

- Fix config loading to fail on `offload l2tp no;` when L2TP offloading is unsupported by the fastd build or the kernel

- Fix assembly Salsa20(/12) implementations accidentally generating the Linux- specific `.note.GNU-stack` ELF section on non-Linux systems

  This is unlikely to have caused any issues, as other systems should just ignore the unknown section.

- Status socket: - Fix interface name information with L2TP offloading - Add per-peer MTU information

- Documentation: - Fix incorrect “persist interface” examples - Improve explanation of `float` option

- Build: - Fix build on macOS (again) - Fix build with Meson 0.49 (the minimum version marked as supported by fastd)

## Other changes

- Add support for Indirect Branch Tracking and Shadow Stacks on x86

  The assembly Salsa20(/12) implementations have been marked compatible with IBT and SHSTK, which are part of Intel CET (Control-flow Enforcement Technology) and can be enabled using the `-fcf-protection` GCC option.

- The file `COPYRIGHT` has been renamed to `LICENSE`

- The vendored version of libmnl that is used with `libmnl_builtin=true` has been updated to 1.0.5