Page MenuHomeFreeBSD

ip_input: packet filters shall not modify m_pkthdr.rcvif
ClosedPublic

Authored by glebius on Nov 9 2021, 8:34 PM.

Details

Summary

Quick review confirms that they do not, also IPv6 doesn't expect
such a change in mbuf. In IPv4 this appeared in 0aade26e6d061,
which doesn't seem to have a valid explanation why.

Diff Detail

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

Event Timeline

The reason for the change of the interface might be located in the pfil_run_hooks.
May be @kp can tell something more about the magic there.

The reason for the change of the interface might be located in the pfil_run_hooks.
May be @kp can tell something more about the magic there.

Sure, the expectations in 0aade26e6d061 were that pfil(9) might change ifp. However, AFAIK, this doesn't happen with any filter. Also, I would assert that we should not leave such possibility. Look, we already did some ifp checks before pfil_run_hooks() and the packet passed this checks. If the interface changes, what should we do? Any legitimate reason for pkthdr.rcvif to change is decapsulation and thus arrival on some tunnel interface. This decapsulation is never performed by pfil(9) filter. If somebody wants to create such decapsulation as a pfil(9) filter, they shall pass decapsulated packet to netisr, not return it back to ip_input(). In this case decapsulated packet would be processed with correct new rcvif by new invocation of ip_input.

This revision is now accepted and ready to land.Nov 10 2021, 7:19 AM

I've not gone digging to find out why pfil(9) assumed rcvif could change, but I follow Gleb's reasoning. There doesn't seem to be any reason why a firewall might want to change it.
pf and ipfw don't change it (although they do sometimes set it for packets they generate, but that's not relevant for this change), and ipf never even looks at it, so this change is safe.