| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
defined. Remove eaction_create_compat() and use designated initializers to
initialize eaction_opcodes structure.
Obtained from: Yandex LLC
|
|
|
|
|
|
|
|
| |
These are mostly cosmetical, no functional change.
Found with devel/coccinelle.
Reviewed by: ae
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It allows implementing loadable kernel modules with new actions and
without needing to modify kernel headers and ipfw(8). The module
registers its action handler and keyword string, that will be used
as action name. Using generic syntax user can add rules with this
action. Also ipfw(8) can be easily modified to extend basic syntax
for external actions, that become a part base system.
Sample modules will coming soon.
Obtained from: Yandex LLC
Sponsored by: Yandex LLC
|
|
|
|
|
|
|
| |
It should match with the type field in struct ipfw_obj_tlv.
Obtained from: Yandex LLC
Sponsored by: Yandex LLC
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the same opcode.
o Reduce number of times classifier callback is called. It is
redundant to call it just after find_op_rw(), since the last
does call it already and can have all results.
o Do immediately opcode rewrite in the ref_opcode_object().
This eliminates additional classifier lookup later on bulk update.
For unresolved opcodes the behavior still the same, we save information
from classifier callback in the obj_idx array, then perform automatic
objects creation, then perform rewriting for opcodes using indeces
from created objects.
Obtained from: Yandex LLC
Sponsored by: Yandex LLC
|
|
|
|
|
|
| |
ip_fw_table.c into ip_fw_sockopt.c and make them static.
Obtained from: Yandex LLC
|
|
|
|
| |
Found with devel/coccinelle.
|
|
|
|
|
|
|
|
|
|
| |
When we guess the nature of the outbound packet (output vs. forwarding) we need
to take bridges into account. When bridging the input interface does not match
the output interface, but we're not forwarding. Similarly, it's possible for the
interface to actually be the bridge interface itself (and not a member interface).
PR: 202351
MFC after: 2 weeks
|
|
|
|
|
| |
Obtained from: Yandex LLC
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
| |
taskqueue_enqueue() was changed to support both fast and non-fast
taskqueues 10 years ago in r154167. It has been a compat shim ever
since. It's time for the compat shim to go.
Submitted by: Howard Su <howard0su@gmail.com>
Reviewed by: sephe
Differential Revision: https://reviews.freebsd.org/D5131
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the DIOCRSETADDRS ioctl() handler we allocate a table for struct pfr_addrs,
which is processed in pfr_set_addrs(). At the users request we also provide
feedback on the deleted addresses, by storing them after the new list
('bcopy(&ad, addr + size + i, sizeof(ad));' in pfr_set_addrs()).
This means we write outside the bounds of the buffer we've just allocated.
We need to look at pfrio_size2 instead (i.e. the size the user reserved for our
feedback). That'd allow a malicious user to specify a smaller pfrio_size2 than
pfrio_size though, in which case we'd still read outside of the allocated
buffer. Instead we allocate the largest of the two values.
Reported By: Paul J Murphy <paul@inetstat.net>
PR: 207463
MFC after: 5 days
Differential Revision: https://reviews.freebsd.org/D5426
|
|
|
|
|
|
|
| |
Due to integer overflow CS4 token was handled as BE.
PR: 207459
MFC after: 1 week
|
|
|
|
|
|
|
| |
local copy proto that we very carefully set beforehands. skw being NULL is
perfectly valid there.
Obtained from: OpenBSD (henning)
|
|
|
|
| |
Found by: PVS-Studio
|
|
|
|
| |
via sys/mbuf.h
|
|
|
|
| |
for dummynet schedulers
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
is followed by another structure (rr_schk) whose size must be set
in the schk_datalen field of the descriptor.
Not allocating the memory may cause other memory to be overwritten
(though dn_schk is 192 bytes and rr_schk only 12 so we may be lucky
and end up in the padding after the dn_schk).
This is a merge candidate for stable and 10.3
MFC after: 3 days
|
| |
|
| |
|
|
|
|
| |
Add checks for parameters overflowing 32 bit.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
in computing a shift index. The error was due to the use of mixed
fls() / __fls() functions in another implementation of qfq.
To avoid that the problem occurs again, properly document which
incarnation of the function we need.
Note that the bug only affects QFQ in FreeBSD head from last july, as
the patch was not merged to other versions.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are number of radix consumers in kernel land (pf,ipfw,nfs,route)
with different requirements. In fact, first 3 don't have _any_ requirements
and first 2 does not use radix locking. On the other hand, routing
structure do have these requirements (rnh_gen, multipath, custom
to-be-added control plane functions, different locking).
Additionally, radix should not known anything about its consumers internals.
So, radix code now uses tiny 'struct radix_head' structure along with
internal 'struct radix_mask_head' instead of 'struct radix_node_head'.
Existing consumers still uses the same 'struct radix_node_head' with
slight modifications: they need to pass pointer to (embedded)
'struct radix_head' to all radix callbacks.
Routing code now uses new 'struct rib_head' with different locking macro:
RADIX_NODE_HEAD prefix was renamed to RIB_ (which stands for routing
information base).
New net/route_var.h header was added to hold routing subsystem internal
data. 'struct rib_head' was placed there. 'struct rtentry' will also
be moved there soon.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
if more than 64 distinct values had been used.
Table value code uses internal objhash API which requires unique key
for each object. For value code, pointer to the actual value data
is used. The actual problem arises from the fact that 'actual' e.g.
runtime data is stored in array and that array is auto-growing. There is
special hook (update_tvalue() function) which is used to update the pointers
after the change. For some reason, object 'key' was not updated.
Fix this by adding update code to the update_tvalue().
Sponsored by: Yandex LLC
|
| |
|
|
|
|
|
|
| |
compiled into the kernel. Ideally lots more code would just not
be called (or compiled in) in that case but that requires a lot
more surgery. For now try to make IP-less kernels compile again.
|
| |
|
| |
|
|
|
|
| |
Reviewed by: ae
|
|
|
|
| |
Differential Revision: https://reviews.freebsd.org/D4763
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
panics when unloading the dummynet and IPFW modules:
- The callout drain function can sleep and should not be called having
a non-sleepable lock locked. Remove locks around "ipfw_dyn_uninit(0)".
- Add a new "dn_gone" variable to prevent asynchronous restart of
dummynet callouts when unloading the dummynet kernel module.
- Call "dn_reschedule()" locked so that "dn_gone" can be set and
checked atomically with regard to starting a new callout.
Reviewed by: hiren
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D3855
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Vast majority of rtalloc(9) users require only basic info from
route table (e.g. "does the rtentry interface match with the interface
I have?". "what is the MTU?", "Give me the IPv4 source address to use",
etc..).
Instead of hand-rolling lookups, checking if rtentry is up, valid,
dealing with IPv6 mtu, finding "address" ifp (almost never done right),
provide easy-to-use API hiding all the complexity and returning the
needed info into small on-stack structure.
This change also helps hiding route subsystem internals (locking, direct
rtentry accesses).
Additionaly, using this API improves lookup performance since rtentry is not
locked.
(This is safe, since all the rtentry changes happens under both radix WLOCK
and rtentry WLOCK).
Sponsored by: Yandex LLC
|
|
|
|
|
|
|
|
| |
It is called when last reference to named object is going to be released
and allows to do additional cleanup for implementation of named objects.
Obtained from: Yandex LLC
Sponsored by: Yandex LLC
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For example:
00002 0 0 (19s) PARENT 1 tcp 10.10.0.5 0 <-> 0.0.0.0 0
00002 4 412 (1s) LIMIT tcp 10.10.0.5 25848 <-> 10.10.0.7 22
00002 10 777 (1s) LIMIT tcp 2001:894:5a24:653::503:1 52023 <-> 2001:894:5a24:653:ca0a:a9ff:fe04:3978 22
00002 0 0 (17s) PARENT 1 tcp 2001:894:5a24:653::503:1 0 <-> 80f3:70d:23fe:ffff:1005:: 0
Fix this by zeroing the unused address, as is done for IPv4:
00002 0 0 (18s) PARENT 1 tcp 10.10.0.5 0 <-> 0.0.0.0 0
00002 36 14952 (1s) LIMIT tcp 10.10.0.5 25848 <-> 10.10.0.7 22
00002 0 0 (0s) PARENT 1 tcp 2001:894:5a24:653::503:1 0 <-> :: 0
00002 4 345 (274s) LIMIT tcp 2001:894:5a24:653::503:1 34131 <-> 2001:470:1f11:262:ca0a:a9ff:fe04:3978 22
MFC after: 2 weeks
|
| |
|
|
|
|
|
|
|
|
|
|
| |
new return codes of -1 were mistakenly being considered "true". Callout_stop
now returns -1 to indicate the callout had either already completed or
was not running and 0 to indicate it could not be stopped. Also update
the manual page to make it more consistent no non-zero in the callout_stop
or callout_reset descriptions.
MFC after: 1 Month with associated callout change.
|
|
|
|
| |
Submitted by: Denis Schneider <v1ne2go at gmail>
|
|
|
|
|
|
| |
Problem was introduced in r272840 when converting tablearg value to 0.
Submitted by: Denis Schneider <v1ne2go at gmail>
|
|
|
|
|
|
|
|
| |
r289932 accidentally broke the rule skip calculation. The address family
argument to PF_ANEQ() is now important, and because it was set to 0 the macro
always evaluated to false.
This resulted in incorrect skip values, which in turn broke the rule
evaluations.
|
|
|
|
|
|
|
|
| |
Actually, object classify callbacks can skip some opcodes, that could
be rewritten. We will deteremine real numbed of rewritten opcodes a bit
later in this function.
Reported by: David H. Wolfskill <david at catwhisker dot org>
|
|
|
|
|
|
|
|
|
|
|
| |
check_ipfw_rule_body() function. This function is intended to just
determine that rule has some opcodes that can be rewrited. Then the
ref_rule_objects() function will determine real number of rewritten
opcodes using classify callback.
Reviewed by: melifaro
Obtained from: Yandex LLC
Sponsored by: Yandex LLC
|
|
|
|
|
|
|
|
|
| |
object name correctness. Each type of object can do more strict checking
in own implementation. Do such checks for tables in check_table_name().
Reviewed by: melifaro
Obtained from: Yandex LLC
Sponsored by: Yandex LLC
|
|
|
|
|
|
| |
Reviewed by: melifaro
Obtained from: Yandex LLC
Sponsored by: Yandex LLC
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using route-to (or reply-to) pf sends the packet directly to the output
interface. If that interface doesn't support checksum offloading the checksum
has to be calculated in software.
That was already done in the IPv4 case, but not for the IPv6 case. As a result
we'd emit packets with pseudo-header checksums (i.e. incorrect checksums).
This issue was exposed by the changes in r289316 when pf stopped performing full
checksum calculations for all packets.
Submitted by: Luoqi Chen
MFC after: 1 week
|
|
|
|
| |
Differential Revision: https://reviews.freebsd.org/D3927
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In certain configurations (mostly but not exclusively as a VM on Xen) pf
produced packets with an invalid TCP checksum.
The problem was that pf could only handle packets with a full checksum. The
FreeBSD IP stack produces TCP packets with a pseudo-header checksum (only
addresses, length and protocol).
Certain network interfaces expect to see the pseudo-header checksum, so they
end up producing packets with invalid checksums.
To fix this stop calculating the full checksum and teach pf to only update TCP
checksums if TSO is disabled or the change affects the pseudo-header checksum.
PR: 154428, 193579, 198868
Reviewed by: sbruno
MFC after: 1 week
Relnotes: yes
Sponsored by: RootBSD
Differential Revision: https://reviews.freebsd.org/D3779
|
|
|
|
|
|
| |
PR: 203459
Submitted by: groos at xiplink.com
MFC after: 2 weeks
|