Improper ND length validation causes infinite loops in OpenBSD slaacd and rad

In OpenBSD through 7.8, the slaacd and rad daemons have an infinite loop when they receive a crafted ICMPv6 Neighbor Discovery (ND) option (over a local network) with length zero, because of an "nd_opt_len * 8 - 2" expression with no preceding check for whether nd_opt_len is zero.

The normalized record identifies the following OpenBSD deployment scope as affected:

• OpenBSD from 0 through 7.8, using the record's custom version semantics.
• The affected components are the slaacd and rad daemons; the record sets the default status outside the affected range to unaffected.
• OpenBSD provides a fix for branch 7.7 in erratum 035_v6daemons and for branch 7.8 in erratum 029_v6daemons.

The inspected evidence does not establish a branch-specific fixed release for versions older than 7.7, and the status of parallel or later branches should not be inferred from a fix for a different branch.

The slaacd and rad daemons parse ICMPv6 Neighbor Discovery options received from the local network. When the option length field nd_opt_len is zero, the code evaluates nd_opt_len * 8 - 2 without first rejecting the zero value. The invalid value can prevent the parser's length and pointer progression from advancing, resulting in an infinite loop while processing the packet. The OpenBSD fix adds a check in parse_ra and debug_log_ra in sbin/slaacd/engine.c, and in parse_rs in usr.sbin/rad/engine.c. Exploitation requires the attacker to send a crafted ND packet over the same or an adjacent local network; the record does not establish data disclosure, data modification, code execution, or privilege escalation. The weakness is improper validation of a specified input quantity that manifests as a loop with no reachable exit.

The flaw is reachable from an adjacent or local network, requires no authentication, requires no user interaction, and is recorded as low complexity to trigger. The trigger is an ICMPv6 ND option whose length field is zero, sent to an affected daemon. The normalized record does not mark the vulnerability as known exploited and sets public exploit to false; that status does not prove that exploitation has never occurred. Research also returned a GitHub page claiming a proof of concept, but that page is not treated as confirmed public-exploit evidence in this entry. No confirmed evidence establishes exploitation from outside the adjacent-network boundary.

The direct technical effect is an infinite loop in the affected daemon when it processes an invalid ND option. This can cause loss of availability for slaacd, rad, or the network functions they provide, with the initial reach limited to systems receiving the packet from an adjacent network. The condition requires neither privileges nor authentication and does not require user interaction. The record does not establish a change in privilege scope, disclosure of data, modification of data, code execution, or privilege escalation. The practical disruption depends on which daemon is enabled, which interfaces receive the traffic, and how the system restores the affected service.

A malicious packet from an adjacent network can leave the affected daemon unable to make progress and unable to continue normal processing of related traffic. This could disrupt IPv6 functions provided by slaacd or degrade Router Advertisement service provided by rad. Operational consequences may include loss or delay of IPv6 address configuration, degraded IPv6 connectivity, or manual intervention to restore the daemon. The available evidence supports an availability impact only; it does not show that the flaw exposes data, modifies data, or gives the attacker system control.

1. Apply the official OpenBSD fix for the branch in use: erratum 035_v6daemons for OpenBSD 7.7, or erratum 029_v6daemons for OpenBSD 7.8. These patches reject a zero option length before the option-length calculation is performed.
2. If applying the source patch, rebuild and install both slaacd and rad after patching sbin/slaacd/engine.c and usr.sbin/rad/engine.c. Applying the patch without replacing the running binaries is insufficient.
3. For releases older than 7.7, obtain the corresponding update from OpenBSD or its stable branch; the inspected evidence does not provide an exact erratum number for those branches.
4. Until updating, reduce the ability of untrusted local-network devices to send ICMPv6 ND traffic to interfaces handled by slaacd or rad where the network design permits. Treat this as a precautionary exposure-reduction measure, not as a vendor-confirmed workaround.
5. After updating, verify that the binaries for both daemons were replaced, that the services are operating normally, and that the relevant interfaces continue processing Router Advertisements or Router Solicitations as expected.

1. Inventory OpenBSD systems running or enabling slaacd and rad, especially systems whose interfaces accept Router Advertisements or Router Solicitations from networks that are not fully trusted.
2. Confirm that the branch-specific OpenBSD erratum has been applied and that both slaacd and rad were rebuilt and installed as instructed.
3. For source-built systems, inspect sbin/slaacd/engine.c to verify that parse_ra and debug_log_ra handle nd_opt_len == 0 before evaluating nd_opt_len * 8 - 2, and inspect usr.sbin/rad/engine.c in parse_rs.
4. Review packet captures or local-network monitoring for ICMPv6 Neighbor Discovery packets containing an option with a zero length field. This is directly related to the vulnerable condition, not an OpenBSD-published IOC.
5. Monitor for a daemon that stops making progress, consumes abnormal CPU, or stops processing ND activity after receiving malformed traffic. The absence of these signs does not prove that a system is safe.