Page MenuHomeFreeBSD

PF_KEY socket: limit the length of copied socket address
ClosedPublic

Authored by kib on Aug 4 2026, 3:56 PM.
Tags
None
Referenced Files
F171276315: D58646.id184022.diff
Thu, Sep 10, 1:47 AM
F171239087: D58646.diff
Wed, Sep 9, 6:36 PM
Unknown Object (File)
Tue, Sep 8, 12:55 PM
Unknown Object (File)
Mon, Sep 7, 5:14 PM
Unknown Object (File)
Mon, Sep 7, 2:56 PM
Unknown Object (File)
Mon, Sep 7, 12:59 PM
Unknown Object (File)
Mon, Sep 7, 3:57 AM
Unknown Object (File)
Sun, Sep 6, 10:11 AM

Details

Summary
for SADB_UPDATE op SADB_X_EXT_NEW_ADDRESS_SRC/DST extensions, by
checking the sa_len matching the address family requirements before
doing the copy.

Also convert KEY_SETSECASIDX() and KEY_SETSECSPIDX() to functions and
apply the same sa_len clamping there as well.

See https://github.com/0xdeadbeefnetwork/pfkey-sadb-overflow

PR:     297264
Tested by: Wafa Hamzah <wafah@nvidia.com>

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

kib requested review of this revision.Aug 4 2026, 3:56 PM

Do the KEY_SETSECASIDX and KEY_SETSECSPIDX macros need to be fixed too? There are quite a few places in this file that copy sockaddrs around, but so far I didn't find any others without checks.

sys/netipsec/key.c
5380

I suspect these checks should be done before the copying, rather. key_checksockaddrs() validates the socket lengths, but it happens too late.

kib marked an inline comment as done.Aug 4 2026, 9:13 PM
kib added inline comments.
sys/netipsec/key.c
5380

After sa_len is clamped, I do not think it matter.

kib marked an inline comment as done.
kib edited the summary of this revision. (Show Details)

Handle KEY_SETSECASIDX() and KEY_SETSECSPIDX().

sys/netipsec/key.c
593

Stray backslash here.

5380

But no clamping is needed, we can just check the sockaddr earlier. Moreover, since sizeof(union sockaddr_union) == sizeof(struct sockaddr_in6), the clamping will hide invalid socklens for AF_INET6 sockaddrs.

kib marked 2 inline comments as done.Aug 4 2026, 9:38 PM
kib added inline comments.
sys/netipsec/key.c
5380

I think the current code is easier to follow, but ok.

kib marked an inline comment as done.
kib edited the summary of this revision. (Show Details)

Not an expert here.

markj added inline comments.
sys/netipsec/key.c
599

Looking through all the callers of the two macros, we are already using key_checksockaddrs() to validate the sockaddrs everywhere except in one place: key_allocsa_tunnel(). The sockaddrs passed to key_allocsa_tunnel() are set up in ipcomp4_nonexp_encapcheck() and ipcomp6_nonexp_encapcheck().

So, I think we can remove the clamping. I prefer to avoid clamping if possible, I think it will hide bugs.

ipcomp6_nonexp_encapcheck() looks weird: it sets sa_family = AF_INET but treats them as sockaddr_in6 addresses. Is that a copy-paste bug? If so, we can fix that, and then make the two helpers assert that key_checksockaddrs() passes.

This revision is now accepted and ready to land.Thu, Aug 13, 10:28 PM
kib marked an inline comment as done.Thu, Aug 13, 11:14 PM
kib added inline comments.
sys/netipsec/key.c
599

The mbufs passed to ipcompX_nonexp_encapcheck() are already checked to be at least the required length, in ip_encap.c::encap_input(), I believe. This is passed through the ipv4/6_encap_cfg structure min_length member. After that, the sockaddrs for key_allocsa_tunnel should pass the invariant by construction. I just removed the clamping from key_setsec* helpers.

I believe that you are right about ipcomp6_nonexp_encapcheck() setting the wrong family, I do not see how the AF_INET could be correct there. But I am not set up to test it. I just added the patch to change the family.

kib marked an inline comment as done.

Constify key_checksockaddrs() args.
Remove clamping.
Assert that key_checksockaddrs() pass for helpers.
Change the socket address family in ipcomp6_nonexp_encapcheck().

This revision now requires review to proceed.Thu, Aug 13, 11:28 PM
This revision is now accepted and ready to land.Fri, Aug 14, 12:48 PM