Page MenuHomeFreeBSD

pf: Handle unmapped mbufs when computing checksums
ClosedPublic

Authored by markj on Mar 22 2021, 2:40 PM.
Tags
None
Referenced Files
F106156168: D29378.diff
Thu, Dec 26, 7:50 AM
Unknown Object (File)
Fri, Dec 13, 2:07 PM
Unknown Object (File)
Mon, Dec 2, 11:55 AM
Unknown Object (File)
Nov 19 2024, 2:55 PM
Unknown Object (File)
Nov 14 2024, 2:21 AM
Unknown Object (File)
Nov 12 2024, 5:43 PM
Unknown Object (File)
Oct 9 2024, 1:48 AM
Unknown Object (File)
Oct 6 2024, 5:48 AM

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 37991
Build 34880: arc lint + arc unit

Event Timeline

markj requested review of this revision.Mar 22 2021, 2:40 PM

I see a call in ipfw, I guess that needs to be updated too. Seems time to introduce a new subroutine to handle this.

sys/netpfil/pf/pf.c
5582

Presumably we'd have to do this here as well.

5595

And here?

5758

And here?

5873

And here?

5880

And here?

sys/netpfil/pf/pf.c
5595

I believe this treatment isn't needed when we're only checksumming a protocol header.

sys/netpfil/pf/pf.c
5595

And here?

5595

No, since this is just the IP header. Unmapped mbufs are a problem for checksums only on payload data.

5758

Yes.

markj marked 2 inline comments as done.

Handle more cases pointed out by Kristof.

sys/netpfil/pf/pf.c
5873

These seem a bit tricky. mb_unmapped_to_ext() frees the chain upon failure, but this function and its callers can't really do that. We are also assuming in general that the first mbuf in the chain is preserved, otherwise mb_unmapped_to_ext() would invalidate some pointers in its callers.

kp added inline comments.
sys/netpfil/pf/pf.c
5873

It's tempting to 'fix' this by calling mb_unmapped_to_ext() in pf_check_in()/pf_check_out(), so that we restore the assumption that it's safe to access packet data.
Probably not the best idea though.

Is there a straightforward way of asserting that an mbuf is or is not unmapped? Just adding an assertion here would at least make future debugging easier.

This revision is now accepted and ready to land.Mar 22 2021, 3:57 PM
sys/netpfil/pf/pf.c
5873

You have to check the entire chain to see if any mbufs in the chain have M_EXTPG set in m_flags. However, it might be nice to have some kind of M_ASSERTMAPPED(m) wrapper for that the way we have a M_ASSERTPKTHDR() macro.

I see a call in ipfw, I guess that needs to be updated too. Seems time to introduce a new subroutine to handle this.

It seems we have first report about panic in the related code: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255164