FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=releng%2F13.3 2023-08-23T17:43:25Z 2023-08-23T17:43:25Z Warner Losh imp@FreeBSD.org 2023-08-22T01:31:27Z urn:sha1:3bc80996974a61a4223eae4c1ccd47b6ee32a48a Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/ Similar commit in current: (cherry picked from commit 685dc743dc3b) 2023-07-14T10:07:58Z Doug Rabson dfr@FreeBSD.org 2023-05-24T13:11:37Z urn:sha1:b22299c457b21d77fc5770b9f1a9043487b25ed9 Redirect rules use PFIL_IN and PFIL_OUT events to allow packet filter rules to change the destination address and port for a connection. Typically, the rule triggers on an input event when a packet is received by a router and the destination address and/or port is changed to implement the redirect. When a reply packet on this connection is output to the network, the rule triggers again, reversing the modification. When the connection is initiated on the same host as the packet filter, it is initially output via lo0 which queues it for input processing. This causes an input event on the lo0 interface, allowing redirect processing to rewrite the destination and create state for the connection. However, when the reply is received, no corresponding output event is generated; instead, the packet is delivered to the higher level protocol (e.g. tcp or udp) without reversing the redirect, the reply is not matched to the connection and the packet is dropped (for tcp, a connection reset is also sent). This commit fixes the problem by adding a second packet filter call in the input path. The second call happens right before the handoff to higher level processing and provides the missing output event to allow the redirect's reply processing to perform its rewrite. This extra processing is disabled by default and can be enabled using pfilctl: pfilctl link -o pf:default-out inet-local pfilctl link -o pf:default-out6 inet6-local PR: 268717 Reviewed-by: kp, melifaro MFC-after: 2 weeks Differential Revision: https://reviews.freebsd.org/D40256 (cherry picked from commit 5ab151574c8a1824c6cd8eded28506cb983284bc) 2023-03-20T13:00:56Z Mark Johnston markj@FreeBSD.org 2023-03-06T20:06:00Z urn:sha1:795fda214f11ebb58b335fd064f736708df6b3ff The assertions added in commit b0ccf53f2455 ("inpcb: Assert against wildcard addrs in in_pcblookup_hash_locked()") revealed that protocol layers may pass the unspecified address to in_pcblookup(). Add some checks to filter out such packets before we attempt an inpcb lookup: - Disallow the use of an unspecified source address in in_pcbladdr() and in6_pcbladdr(). - Disallow IP packets with an unspecified destination address. - Disallow TCP packets with an unspecified source address, and add an assertion to verify the comment claiming that the case of an unspecified destination address is handled by the IP layer. Reported by: syzbot+9ca890fb84e984e82df2@syzkaller.appspotmail.com Reported by: syzbot+ae873c71d3c71d5f41cb@syzkaller.appspotmail.com Reported by: syzbot+e3e689aba1d442905067@syzkaller.appspotmail.com Reviewed by: glebius, melifaro MFC after: 2 weeks Sponsored by: Klara, Inc. Sponsored by: Modirum MDPay Differential Revision: https://reviews.freebsd.org/D38570 (cherry picked from commit 713264f6b8bc5f927dd52cf8ffcccfa397034fec) 2023-02-02T00:01:06Z Michael Tuexen tuexen@FreeBSD.org 2022-11-07T07:50:51Z urn:sha1:9983b0126bbad586e7b1748719da5c8132ec3e4d Including sctp_var.h requires INET to be defined if IPv4 support is needed. (cherry picked from commit 126f8248ccfee8e9252a8b449694b8619738599f) 2021-12-29T10:52:52Z Bjoern A. Zeeb bz@FreeBSD.org 2021-12-26T15:33:48Z urn:sha1:a7e7700fa741d64a31e9d7596175fc0461687b86 RFC792,1009,1122 state the original conditions for sending a redirect. RFC1812 further refine these. ip_forward() still sepcifies the checks originally implemented for these (we do slightly more/different than suggested as makes sense). The implementation added in 8ad114c082a159c0dde95aa35d2e3e108aa30a75 to ip_tryforward() however is flawed and may send a "multi-hop" redirects (to a host not on the directly connected network). Do proper checks in ip_tryforward() to stop us from sending redirects in situations we may not. Keep as much logic out of ip_tryforward() and in ip_redir_alloc() and only do the mbuf copy once we are sure we will send a redirect. While here enhance and fix comments as to which conditions are handled for sending redirects in various places. Reported by: pi (on net@ 2021-12-04) Sponsored by: Dr.-Ing. Nepustil & Co. GmbH Reviewed by: cy, others (earlier versions) Differential Revision: https://reviews.freebsd.org/D33274 (cherry picked from commit f389439f50fc4c27d15d3017b622270e25ba71c7) 2021-09-07T21:25:06Z Zhenlei Huang zlei.huang@gmail.com 2021-08-22T22:28:47Z urn:sha1:e8df60a69a0e70905fb9aa3e9ad7bc4ca0f6a2b2 Implement kernel support for RFC 5549/8950. * Relax control plane restrictions and allow specifying IPv6 gateways for IPv4 routes. This behavior is controlled by the net.route.rib_route_ipv6_nexthop sysctl (on by default). * Always pass final destination in ro->ro_dst in ip_forward(). * Use ro->ro_dst to exract packet family inside if_output() routines. Consistently use RO_GET_FAMILY() macro to handle ro=NULL case. * Pass extracted family to nd6_resolve() to get the LLE with proper encap. It leverages recent lltable changes committed in c541bd368f86. Presence of the functionality can be checked using ipv4_rfc5549_support feature(3). Example usage: route add -net 192.0.0.0/24 -inet6 fe80::5054:ff:fe14:e319%vtnet0 Differential Revision: https://reviews.freebsd.org/D30398 (cherry picked from commit 62e1a437f3285e785d9b35a476d36a469a90028d) 2021-06-17T08:08:59Z Zhenlei Huang zlei.huang@gmail.com 2021-05-18T20:51:37Z urn:sha1:7da8312f7bf050be4fe436ea66ac46414312ae26 The current implement of ip_input() reject packets destined for 169.254.0.0/16, but not those original from 169.254.0.0/16 link-local addresses. Fix to fully respect RFC 3927 section 2.7. PR: 255388 Reviewed by: donner, rgrimes, karels Differential Revision: https://reviews.freebsd.org/D29968 Reviewed by: rgrimes, donner, karels, marcus, emaste Differential Revision: https://reviews.freebsd.org/D30374 (cherry picked from commit 3d846e48227e2e78c1e7b35145f57353ffda56ba) (cherry picked from commit 03b0505b8fe848f33f2f38fe89dd5538908c847e) 2021-03-13T20:19:17Z Alexander V. Chernikov melifaro@FreeBSD.org 2021-03-08T21:35:41Z urn:sha1:8aafa7a0276302a0dcc3d0bd78b4d3842dfd1640 Summary: This fixes rtentry leak for the cloned interfaces created inside the VNET. Loopback teardown order is `SI_SUB_INIT_IF`, which happens after `SI_SUB_PROTO_DOMAIN` (route table teardown). Thus, any route table operations are too late to schedule. As the intent of the vnet teardown procedures to minimise the amount of effort by doing global cleanups instead of per-interface ones, address this by adding a relatively light-weight routing table cleanup function, `rib_flush_routes()`. It removes all remaining routes from the routing table and schedules the deletion, which will happen later, when `rtables_destroy()` waits for the current epoch to finish. Test Plan: ``` set_skip:set_skip_group_lo -> passed [0.053s] tail -n 200 /var/log/messages | grep rtentry ``` PR: 253998 Reported by: rashey at superbox.pl Reviewed By: kp Differential Revision: https://reviews.freebsd.org/D29116 (cherry picked from commit b1d63265ac399112b3bca36c3d75df1a3c2c8102) 2020-11-29T19:43:33Z Alexander V. Chernikov melifaro@FreeBSD.org 2020-11-29T19:43:33Z urn:sha1:d1d941c5b910e075495cb06b92a99d3a3e7a3d6c ROUTE_MPATH is the new config option controlling new multipath routing implementation. Remove the last pieces of RADIX_MPATH-related code and the config option. Reviewed by: glebius Differential Revision: https://reviews.freebsd.org/D27244 2020-11-13T18:25:07Z Ed Maste emaste@FreeBSD.org 2020-11-13T18:25:07Z urn:sha1:360d1232ab075d5825b2ae860dd1718084684413 Discussed with: gnn MFC with: r367628