A logic bug in remove_protocol() meant that it would remove (leak) all
structures in the list preceding the one intended for removal.
PR: 245971
Submitted by: joost@jodocus.org (original version)
MFC after: 1 week
Update a bunch of Makefile.depend files as
a result of adding Makefile.depend.options files
Reviewed by: bdrewery
MFC after: 1 week
Sponsored by: Juniper Networks
Differential Revision: https://reviews.freebsd.org/D22494
Leaf directories that have dependencies impacted
by options need a Makefile.depend.options file
to avoid churn in Makefile.depend
DIRDEPS for cases such as OPENSSL, TCP_WRAPPERS etc
can be set in local.dirdeps-options.mk
which can add to those set in Makefile.depend.options
See share/mk/dirdeps-options.mk
Reviewed by: bdrewery
MFC after: 1 week
Sponsored by: Juniper Networks
Differential Revision: https://reviews.freebsd.org/D22469
The previous revision missed the exact same error in a copy paste block
of the same code in another function. Fix the identical case, too.
A DHCP client identifier is simply the hardware type (one byte)
concatenated with the hardware address (some variable number of bytes,
but at most 16). Limit the size of the temporary buffer to match and
the rest of the calculations shake out correctly.
PR: 238022
Reported by: Young <yangx92 AT hotmail.com>
Submitted by: Young <yangx92 AT hotmail.com>
MFC after: I don't plan to but you should feel free
Security: yes
Otherwise they are leaked, allowing an attacker to trigger memory
exhaustion.
This is options.c rev. 1.70 from OpenBSD.
admbugs: 552
Obtained from: OpenBSD
MFC after: 3 days
A mixture of IP or UDP packets with valid and invalid checksum could
cause {ip,udp}_packets_bad_checksum to wrap around to 0, resulting
in a division by zero.
This is packet.c rev. 1.27 from OpenBSD.
admbugs: 552
Obtained from: OpenBSD
MFC after: 3 days
MTU if we've set it once and there were no changes on the DHCP server
side since the last refresh. This is consistent I believe with how dhclient
handles other settings like IP address, mask etc.
Approved by: cem, eugen
Differential Revision: https://reviews.freebsd.org/D18546
r343896 made it such that a non-zero exit status was passed through, but was
still wrong if the script exits on a signal. POSIX does not say what the
WEXITSTATUS macro returns in this case and in practice 0 is a common value.
Instead, translate the wait status into 8 bits the same way as the shell
calculates $?.
Reviewed by: kib, Nash Kaminski
MFC after: 1 week
This is also OpenBSD rev. 1.117, as pointed out by
Ryan Moeller <ryan@ixsystems.com>.
Submitted by: Nash Kaminski <nashkaminski@gmail.com>
MFC after: 1 week
This is being done a separate step to ease importing into other VCSes.
Approved by: re (gjb), will (mentor)
Differential Revision: https://reviews.freebsd.org/D17160
dhclient and ping normally use libcasper services. These are not
available in statically-linked binaries, so when WITHOUT_DYNAMICROOT is
set disable libcasper use, as with rescue builds. Also emit a warning
as it's undesirable to build this way.
Reported by: Michael Dexter
Reviewed by: rgrimes
Tested by: Michael Dexter
Approved by: re (kib)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D17074
This is needed to be able to chroot in the fallback case where
Capsicum is not available.
Reported by: Daniel Braniss <danny@cs.huji.ac.il>
X-MFC with: r337382
Sponsored by: The FreeBSD Foundation
The main dhclient process is Capsicumized but also chroots to
restrict filesystem access. With r322369, pidfile(3) maintains a
directory descriptor for the pidfile, which can cause the chroot
to fail in certain cases. To minimize the problem, only chroot
if we fail to enter capability mode, and store dhclient pidfiles
in a subdirectory of /var/run, thus restricting access via
pidfile(3)'s directory descriptor.
PR: 223327
Reviewed by: cem, oshogbo
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D16584
This check eliminates infinite loop of MTU change / link flap / lease verification / MTU change / link flap etc.
in case of some NIC drivers like em(4) or igb(4).
N.B.: obsolete u_int16_t is used in consistency with the rest of the file.
PR: 229432
Approved by: mav (mentor)
MFC after: 1 week
A more correct way to modernize code that uses __progname is to just
replace each occurance of it with a call to getprogname(3)
Reported by: ian
Reviewed by: imp
- add static in a number of places
- initialize __progname rather than rely on magical extern values
- use nitems() instead of manually spelling it out
- unshadow 'idi'
- teach 'error' that it is '__dead2'
- add missing 'break'
In some cases broken DHCP servers might send invalid MTU value, so allow to
use 'supersede' in dhclient.conf to override this. When superseded value is
0, MTU value is not updated at all.
PR: 206721
Submitted by: novel@
Reported by: <jimp AT pfsense.org>
MFC after: 37 minutes (if you care about 11, please MFC to 11.2)
Relnotes: yes (potentially surprising behavior change w/ broken dhcpd mtu)
Differential Revision: https://reviews.freebsd.org/D15484
When dhclient first starts, if an old IP address exists in the
dhclient.leases file, dhclient(8) sends early DHCPREQUEST message(s)
in an attempt to re-obtain the old IP address again. These messages
contain the old IP as a requested-IP-address option in the message
body (correct) but also use the old IP address as the packet's source
IP (incorrect).
RFC2131 sec 4.1 states:
DHCP messages broadcast by a client prior to that client obtaining
its IP address must have the source address field in the IP header
set to 0.
The use of the old IP as the packet's source address is incorrect if
(a) the computer is now on a different network or (b) it is on the
same network, but the old IP has been reallocated to another host.
Fix dhclient to use 0.0.0.0 as the source IP in this circumstance
without removing any existing functionality. Any previously-used old
IP is still requested in the body of an early DHCPREQUEST message.
PR: 199378
Submitted by: J.R. Oldroyd <fbsd@opal.com>
Reported by: J.R. Oldroyd <fbsd@opal.com>
Reviewed by: cem, asomers, vangyzen
MFC after: 1 week
Sponsored by: Dell EMC
Differential Revision: https://reviews.freebsd.org/D14527
Mostly const-correctness fixes. There were also some variable-shadowing,
unused variable, and a couple of sockaddr type-correctness changes. I also had
trouble with cast-align warnings. I was able to prove that one of them was a
false positive. But ultimately I had to disable the warning program-wide to
deal with the others.
Reviewed by: cem
MFC after: 3 weeks
Sponsored by: Spectra Logic Corp
Differential Revision: https://reviews.freebsd.org/D14460
Mainly focus on files that use BSD 3-Clause license.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
Special thanks to Wind River for providing access to "The Duke of
Highlander" tool: an older (2014) run over FreeBSD tree was useful as a
starting point.
dhclient(8) is chrooted so opening /dev/null always will fail.
In capability world this is also annoying because we getting error that
open(2) is not permitted in Capsicum. dhclient(8) is closing stdio by
precaching fd to /dev/null before chroot.
This is done few lines below daemon(3) function so let's not try to do that
in daemon(3) function.
Reviewed by: cem@
Differential Revision: https://reviews.freebsd.org/D12826
dhclient(8) is failing during boot to connect to the syslog service, because
syslog daemon is started after dhclient(8). This can be reproduced by stooping
syslog daemon and ktrace the dhclient or use kern.trap_enotcap sysctl and boot
the machine. Using the Casper syslog service fix the problem.
Reviewed by: bapt@
Differential Revision: https://reviews.freebsd.org/D12825
When parse_semi fails, free s before returning
parse.c parse_numeric_aggregate
The memory assigned to bufp is complicated, it can either be from the input
parameter buf or allocated locally. Introduce a new variable lbufp to track
when it is assigned locally and to free it when appropriate.
Submitted by: Thomas Rix <trix@juniper.net>
Reviewed by: jhb
Approved by: sjg (mentor)
Obtained from: Juniper Networks, Inc.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D9899
lease file.
Some routers set very large values for rebind time (Netgear) and these
are erroneously reported as negative in the leasefile. This was due to a
wrong printf format specification of %ld for an unsigned long on 32-bit
platforms.
They would overflow a signed 32-bit time_t on 32 bit architectures. This
was taken care of, but a compiler optimisation makes this behave
erratically. This could be resolved by adding a -fwrapv flag, but
instead we can check the value before adding the current timestamp to
it.
In the lease file values are still wrong though:
option dhcp-rebinding-time -644245096;
PR: 218980
Reported by: Bob Eager
MFC after: 2 weeks
Also make sure that the renewal is never more than 1/2 * expiry and
rebind never more than 7/4 * renewal (the default values in the spec).
This should allow adjusting high values from the server as well as
making sure the values from the server make sense.
Renewal and rebind times will be adjusted down if the expiry time is set
very high in a server, not the other way around. This change just makes
sure the values keep making sense.
This ensures the storage isn't leaked when non-NULL and the function
returns early, prior to the `free(vendor)` later on in the function.
MFC after: 1 week
Reported by: Coverity
CID: 1007111-1007113
Reviewed by: cem
Sponsored by: Dell EMC Isilon
Differential Revision: D9993
The memory stored by `lease` would have previously been leaked if an
unterminated lease declaration was found in an early-return code path.
MFC after: 1 week
Reported by: clang static analyzer, Coverity
CID: 1007114
Submitted by: Tom Rix <trix@juniper.net>
Sponsored by: Dell EMC Isilon; Juniper, Inc
Differential Revision: D9992
The offending code has been dead ever since the import from OpenBSD in
r195805. OpenBSD later deleted that entire function.
Reported by: Coverity
CID: 500059
MFC after: 4 weeks
Sponsored by: Spectra Logic Corp
the BIOCSETIF ioctl.
The kernel always copies an entire struct ifreq and IPv4 addresses will
always fit in an ifreq.
On systems with pointers larger than 64-bits, the computed size will be
less than the size of struct ifreq, potentially resulting in the kernel
attempting to copyin memory from outside the allocation.
Reviewed by: jhb
Obtained from: CheriBSD
MFC after: 1 week
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D8445
By adding it to the option priorities table.
PR: 184117
Submitted by: Lowell Gilbert <freebsd-bugs-local at be-well.ilk.org>
Reported by: Tomek CEDRO <cederom at tlen.pl>
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D7911
Make dhclient set interface MTU if it was provided.
This version implements MTU setting in dhclient itself before it runs
dhclient-script.
PR: 206721
Submitted by: novel@
Reported by: Jarrod Petz <jlpetz at gmail.com>
Reviewed by: cem, allanjude
Differential Revision: https://reviews.freebsd.org/D5675
Correct switch between current and previous line buffers when
encountering a carriage return in the input.
CID: 1305719
Obtained from: OpenBSD (CVS rev. 1.30)
MFC after: 3 days
A DHCP client identifier is simply the hardware type (one byte) concatenated
with the hardware address (some variable number of bytes, but at most 16).
Limit the size of the temporary buffer to match and the rest of the
calculations shake out correctly.
This is a follow-up to the incorrect r299512, reverted in r300172.
CIDs: 1008682, 1305550
Sponsored by: EMC / Isilon Storage Division
It broke client identifiers because I misunderstood the intent of the code.
There is still a minor issue detected by Coverity (at least, I can't find where
the code proves it isn't an issue). I'll follow up with a better fix for the
CIDs.
Reported by: Ian FREISLICH
Sponsored by: EMC / Isilon Storage Division
There was some confusion about how to limit a hardware address to at most 16
bytes. In some cases it would overrun a byte off the end of the array.
Correct the types and rectify the overrun.
Reported by: Coverity
CIDs: 1008682, 1305550
Sponsored by: EMC / Isilon Storage Division
