Page MenuHomeFreeBSD

IPSEC: ensure that mbufs are mapped if ipsec is enabled
ClosedPublic

Authored by kib on Jul 20 2023, 2:52 PM.
Tags
None
Referenced Files
F103529590: D41112.id.diff
Tue, Nov 26, 3:54 AM
F103529579: D41112.id125010.diff
Tue, Nov 26, 3:54 AM
F103529573: D41112.id124913.diff
Tue, Nov 26, 3:54 AM
Unknown Object (File)
Wed, Nov 20, 8:59 AM
Unknown Object (File)
Sat, Nov 16, 1:43 AM
Unknown Object (File)
Thu, Nov 7, 6:20 PM
Unknown Object (File)
Wed, Nov 6, 7:29 AM
Unknown Object (File)
Thu, Oct 31, 5:23 AM

Details

Summary
Ipsec needs access to packet headers to determine if a policy is
applicable. It seems that typically IP headers are mapped, but the code
is arguably needs to check this before blindly accessing them. Then,
operations like m_unshare() and m_makespace() are not yet ready for
unmapped mbufs.

Ensure that the packet is mapped before calling into IPSEC_OUTPUT().

PR:     272616

Diff Detail

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

Event Timeline

kib requested review of this revision.Jul 20 2023, 2:52 PM
markj added inline comments.
sys/netinet6/ip6_output.c
814

BTW, don't we need to reload ip6 after calling IPSEC_OUTPUT here?

This revision is now accepted and ready to land.Jul 20 2023, 3:06 PM
kib marked an inline comment as done.Jul 20 2023, 3:27 PM
kib added inline comments.
sys/netinet6/ip6_output.c
814

I do not think so, same as for ipv4 case. Either ipsec_output() consumed mbuf chain and would insert a different one into ip{4,6}_output already or sometime in future, or the chain is kept as is. It is not the case that ipsec tinker with the mbuf and return it back.

Are there other existing mb_unmapped_to_ext calls that can now be removed after this? I feel like we added some in IPSec previously.

Oh, those were for checksumming and were removed after Mark fixed checksumming to work on unmapped.

This revision was automatically updated to reflect the committed changes.
kib marked an inline comment as done.