A bug in the pf(4) IPv6 fragment reassembly logic incorrectly uses the last extension header offset from the last received packet instead of from the first packet. Malicious IPv6 packets with different IPv6 extensions could cause a kernel panic or potentially a filtering rule bypass. Only systems leveraging the pf(4) firewall and include packet scrubbing using the recommended 'scrub all in' or similar are affected.
Unless IPv6 reassembly is explicitly disabled, Packet Filter reassembles IPv6 fragments to perform the filtering based on its configuration. The packets are then re-fragmented to comply with the end-to-end nature of the IPv6 fragmentation. When dealing with malicious fragmented IPv6 packets, the functions pf_reassemble6() and pf_refragment6(), may use an improper offset to apply a transformation on the packets. This behavior can have the following impacts: A kernel panic can happen, effectively stopping the system; An unexpected modification of the packets before and after the application of the filtering rules can occur. This may be leveraged to bypass the rules under some circumstances (see Rule bypass p.10). Note that with a GENERIC kernel, the panic drops to the debugger and does not reboot without a manual intervention.