Skip to content
FreeBSDFix Published Updated 4 min readViews unavailable

FreeBSD CVE-2025-24934: Verify the SO_REUSEPORT_LB UDP Fix

Assess CVE-2025-24934 on FreeBSD, verify the fixed branch, and test connected UDP receive filtering without trusting connect() success alone.

FreeBSD Security Advisory FreeBSD-SA-25:09.netinet describes CVE-2025-24934, a SO_REUSEPORT_LB defect affecting connected UDP sockets. The advisory says the kernel failed to check a socket’s connection state when adding it to a load-balancing group, and packet lookup could select a group member even when it was connected. That could let a connected UDP socket receive from an unexpected source, violating the peer-filtering contract applications commonly rely on and potentially enabling spoofing attacks.

The advisory’s affected-version scope is all supported FreeBSD versions, but that does not mean every UDP workload is exposed. It identifies software that sets SO_REUSEPORT_LB on a socket and then connects it as the affected pattern; software that does not use this option is not affected by this advisory. A successful connect(2) call alone does not prove that the running kernel enforces the expected receive boundary.

Establish which kernel is actually running

Start with the installed and running version evidence, not a source tree or a package cache:

freebsd-version -kru
uname -a

Record the output with the host’s update method and supported release branch. With -kru, freebsd-version prints the installed kernel, running kernel, and installed userland versions, in that order. Compare the first two: a corrected kernel on disk is not yet the active kernel if the host has not rebooted. uname -a adds platform and architecture context, but retain the version command output as the patch-level evidence. For a custom or source-built kernel, also retain the source revision and build/install record used to create the running image.

The advisory was announced on 2025-10-22 and listed corrections for stable/15, releng/15.0, stable/14, releng/14.3, stable/13, and releng/13.5. Its release-branch entries included 15.0-BETA2-p1, 14.3-RELEASE-p5, and 13.5-RELEASE-p6; it also published the exact corrected commit hashes for the stable and releng branches. These are historical advisory checkpoints, not a recommendation to run an old release today. Compare the host against the current supported branch and current FreeBSD errata, then confirm it is at or beyond the applicable correction. Do not compare kernel and userland numbers as if they were interchangeable.

Apply the correction through the host’s real update path

FreeBSD’s advisory directs operators to move to a supported stable or release/security branch dated after the correction. For a traditional RELEASE installation on amd64 or arm64, or an i386 installation on FreeBSD 13, its binary procedure uses freebsd-update fetch and freebsd-update install, followed by a reboot. The advisory separately provides source patches for applicable 15.x, 14.x, and 13.x release branches and requires verifying the detached PGP signature before applying and rebuilding. Follow the instructions for the actual branch and installation model; a custom kernel, source-built world, or pkgbase-managed host may need a different supported update procedure.

Do not copy an old patch onto an unrelated branch, mix binaries from different update methods, or infer success from a command’s exit status without checking the resulting running kernel. If the host is beyond the advisory’s listed branches, use the current security branch guidance rather than treating an old patch as a forward-compatible fix. Schedule any required reboot through the service’s change process, then repeat version collection after boot.

Test the connected-peer invariant

At the pinned FreeBSD main-tree test-addition commit in the source links, the ATF cases connect_udp and connect_udp6 each create three loopback UDP sockets, set SO_REUSEPORT_LB on the receiver, and connect that receiver to a peer. They send a datagram from a separate unconnected socket to the bound address and check that it does not become readable on the receiver, then send from the connected peer and expect delivery. This precisely tests the violated contract: unrelated traffic must not be delivered merely because the socket belongs to a load-balancing group. The test-addition commit is not the advisory’s correction commit; verify the installed release branch against its branch-specific corrected revision.

For application review, locate every SO_REUSEPORT_LB call and determine whether that socket can later be connected or used with connected-UDP assumptions. Exercise the relevant peer and address-family paths in an isolated test environment, and assert both negative and positive cases: an unrelated sender is rejected, while the configured peer is received. A generic check that connect() returned zero is not enough. Do not send spoofed traffic at a production service to test this condition.

The regression test is evidence about the tested source revision, not a substitute for verifying the kernel installed on a host or testing every custom networking path. Keep the test result, branch identifier, running-kernel version, and update evidence together so an incident reviewer can reconstruct which code was exercised.

Close the exposure with evidence

Treat the issue as closed only after the host is on a supported corrected branch, the corrected kernel is running, and any application-specific connected-UDP invariant is tested. If the workload does not use SO_REUSEPORT_LB, record that scoped finding rather than applying an unrelated socket rewrite. If it does, avoid relying on connected UDP peer filtering until the kernel correction is confirmed. The advisory states that no workaround is available; replacing the option in application code is not a general remediation unless the service’s design has been reviewed and changed deliberately.

Related:

Sources:

Comments