| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
pf: Fix misdetection of forwarding when net.link.bridge.pfil_bridge is set
If net.link.bridge.pfil_bridge is set we can end up thinking we're forwarding
in pf_test6() because the rcvif and the ifp (output interface) are different.
In that case we're bridging though, and the rcvif the the bridge member on
which the packet was received and ifp is the bridge itself.
If we'd set dir to PF_FWD we'd end up calling ip6_forward() which is
incorrect.
Instead check if the rcvif is a member of the ifp bridge. (In other words, the
if_bridge is the ifp's softc). If that's the case we're not forwarding but
bridging.
PR: 202351
|
|\ \
| |/
| |
| | |
Catch up with proper fix for pf_increase_self_table_size.diff (r287207)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Reapply r196551 which was accidentally reverted by r223637 (update to
OpenBSD pf 4.5).
Fix argument ordering to memcpy as well as the size of the copy in the
(theoretical) case that pfi_buffer_cnt should be greater than ~_max.
This fix the failure when you hit the self table size and force it to be
resized.
Sponsored by: Rubicon Communications (Netgate)
|
| |
| |
| |
| |
| |
| | |
A proper fix reached stable/10 - r287207
This reverts commit 74b3c6d4762659d5014ccefb21e6657f673ab443.
|
| |
| |
| |
| |
| |
| | |
There are too many changes on pf that depends on this change.
This reverts commit 0ab5a7411ff94100549aa771f2085ffdc71f22e7.
|
|\ \
| |/ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fix the copy of addresses passed from userland in table replace command.
The size2 is the maximum userland buffer size (used when the addresses are
copied back to userland).
Obtained from: pfSense
Sponsored by: Rubicon Communications (Netgate)
|
| |
| |
| |
| |
| |
| | |
This reverts commit e47eb2084d73bd81025b9eb23683a704ec9e16e1.
This is now on stable/10, r286961
|
| |
| |
| |
| |
| |
| |
| | |
This reverts commit b74b5b434292ee1c1c1de56c45c21632d0316f68.
This patch is no longer necessary, if something is broken without this we
will fix the offending code.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
| |
Respect pf rule log option before log dropped packets with IP options or
dangerous v6 headers
Reviewed by: gnn, eri
Approved by: gnn, glebius
Obtained from: pfSense
Sponsored by: Netgate
Differential Revision: https://reviews.freebsd.org/D3222
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pf: Always initialise pf_fragment.fr_flags
When we allocate the struct pf_fragment in pf_fillup_fragment() we
forgot to initialise the fr_flags field. As a result we sometimes
mistakenly thought the fragment to not be a buffered fragment.
This resulted in panics because we'd end up freeing the pf_fragment
but not removing it from V_pf_fragqueue (believing it to be part of
V_pf_cachequeue). The next time we iterated V_pf_fragqueue we'd use
a freed object and panic.
While here also fix a pf_fragment use after free in pf_normalize_ip().
pf_reassemble() frees the pf_fragment, so we can't use it any more.
X-MFS-To: releng/10.2
Sponsored by: The FreeBSD Foundation
|
| |
|
|
|
|
|
|
| |
During module unload unlock rules before destroying UMA zones, which
may sleep in uma_drain(). It is safe to unlock here, since we are already
dehooked from pfil(9) and all pf threads had quit.
|
|
|
|
| |
PR: 200222
|
|
|
|
|
|
| |
its 'states' counter.
PR: 182401
|
|
|
|
|
|
| |
- Provide a sleepable lock to protect against ioctl() vs ioctl() races.
- Use the new lock to protect against simultaneous DIOCSTART and/or
DIOCSTOP ioctls.
|
|
|
|
|
|
|
|
|
|
|
| |
pf: Remove frc_direction
We don't use the direction of the fragments for anything. The frc_direction
field is assigned, but never read.
Just remove it.
Differential Revision: https://reviews.freebsd.org/D2825
Reviewed by: gnn
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pf: address family must be set when creating a pf_fragment
Fix a panic when handling fragmented ip4 packets with 'drop-ovl' set.
In that scenario we take a different branch in pf_normalize_ip(), taking us to
pf_fragcache() (rather than pf_reassemble()). In pf_fragcache() we create a
pf_fragment, but do not set the address family. This leads to a panic when we
try to insert that into pf_frag_tree because pf_addr_cmp(), which is used to
compare the pf_fragments doesn't know what to do if the address family is not
set.
Simply ensure that the address family is set correctly (always AF_INET in this
path).
When we try to look up a pf_fragment with pf_find_fragment() we compare (see
pf_frag_compare()) addresses (and family), but also protocol. We failed to
save the protocol to the pf_fragment in pf_fragcache(), resulting in failing
reassembly.
PR: 200330
Differential Revision: https://reviews.freebsd.org/D2824
Reviewed by: gnn
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Improve INET/INET6 scope.
- style(9) declarations.
- Make couple of local functions static.
- Even more fixes to !INET and !INET6 kernels.
In collaboration with pluknet
- Toss declarations to fix regular build and NO_INET6 build.
Differential Revision: https://reviews.freebsd.org/D2823
Reviewed by: gnn
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pf: Fix forwarding detection
If the direction is not PF_OUT we can never be forwarding. Some input packets
have rcvif != ifp (looped back packets), which lead us to ip6_forward() inbound
packets, causing panics.
Equally, we need to ensure that packets were really received and not locally
generated before trying to ip6_forward() them.
Differential Revision: https://reviews.freebsd.org/D2822
Reviewed by: gnn
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pf: Skip firewall for refragmented ip6 packets
In cases where we scrub (fragment reassemble) on both input and output
we risk ending up in infinite loops when forwarding packets.
Fragmented packets come in and get collected until we can defragment. At
that point the defragmented packet is handed back to the ip stack (at
the pfil point in ip6_input(). Normal processing continues.
Eventually we figure out that the packet has to be forwarded and we end
up at the pfil hook in ip6_forward(). After doing the inspection on the
defragmented packet we see that the packet has been defragmented and
because we're forwarding we have to refragment it.
In pf_refragment6() we split the packet up again and then ip6_forward()
the individual fragments. Those fragments hit the pfil hook on the way
out, so they're collected until we can reconstruct the full packet, at
which point we're right back where we left off and things continue until
we run out of stack.
Break that loop by marking the fragments generated by pf_refragment6()
as M_SKIP_FIREWALL. There's no point in processing those packets in the
firewall anyway. We've already filtered on the full packet.
Differential Revision: https://reviews.freebsd.org/D2819
Reviewed by: gnn
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pf: Deal with runt packets
On Ethernet packets have a minimal length, so very short packets get padding
appended to them. This padding is not stripped off in ip6_input() (due to
support for IPv6 Jumbograms, RFC2675).
That means PF needs to be careful when reassembling fragmented packets to not
include the padding in the reassembled packet.
While here also remove the 'Magic from ip_input.' bits. Splitting up and
re-joining an mbuf chain here doesn't make any sense.
Differential Revision: https://reviews.freebsd.org/D2818
Reviewed by: gnn
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Preserve IPv6 fragment IDs accross reassembly and refragmentation
When forwarding fragmented IPv6 packets and filtering with PF we
reassemble and refragment. That means we generate new fragment headers
and a new fragment ID.
We already save the fragment IDs so we can do the reassembly so it's
straightforward to apply the incoming fragment ID on the refragmented
packets.
Differential Revision: https://reviews.freebsd.org/D2817
Reviewed by: gnn
|
|
|
|
|
|
|
|
|
|
|
| |
In the forwarding case refragment the reassembled packets with the same
size as they arrived in. This allows the sender to determine the optimal
fragment size by Path MTU Discovery.
Roughly based on the OpenBSD work by Alexander Bluhm.
Differential Revision: https://reviews.freebsd.org/D2816
Reviewed by: gnn
|
|
|
|
|
|
|
|
| |
Update the pf fragment handling code to closer match recent OpenBSD.
That partially fixes IPv6 fragment handling.
Differential Revision: https://reviews.freebsd.org/D2814
Reviewed by: gnn
|