mirror of
https://github.com/opnsense/src.git
synced 2026-03-16 23:55:19 -04:00
619456bb59
When we receive the packet with the first fragmented part (fragoff=0) we remember the length of the unfragmentable part and the next header (and should probably also remember ECN) as meta-data on the reassembly queue. Someone replying this packet so far could change these 2 (3) values. While changing the next header seems more severe, for a full size fragmented UDP packet, for example, adding an extension header to the unfragmentable part would go unnoticed (as the framented part would be considered an exact duplicate) but make reassembly fail. So do not allow updating the meta-data after we have seen the first fragmented part anymore. The frag6_20 test case is added which failed before triggering an ICMPv6 "param prob" due to the check for each queued fragment for a max-size violation if a fragoff=0 packet was received. MFC after: 3 weeks Sponsored by: Netflix |
||
|---|---|---|
| .. | ||
| acl | ||
| aio | ||
| audit | ||
| auditpipe | ||
| capsicum | ||
| cddl | ||
| common | ||
| devrandom | ||
| fifo | ||
| file | ||
| fs | ||
| geom | ||
| kern | ||
| kqueue | ||
| mac | ||
| mqueue | ||
| net | ||
| netinet | ||
| netinet6 | ||
| netipsec | ||
| netmap | ||
| netpfil | ||
| opencrypto | ||
| pjdfstest | ||
| posixshm | ||
| sys | ||
| vfs | ||
| vm | ||
| Makefile | ||
| Makefile.depend | ||
| Makefile.inc | ||