marius [Wed, 5 Sep 2018 20:47:51 +0000 (20:47 +0000)]
MFC: r338304
The read accessors generated by __BUS_ACCESSOR() have the problem that
they don't check the result of BUS_READ_IVAR(9) and silently return stack
garbage on failure in case a bus doesn't implement a particular instance
variable for example. With MMC bridges not providing MMCBR_IVAR_RETUNE_REQ,
yet, this in turn can cause mmc(4) to get into a state in which re-tuning
seems to be necessary but is inappropriate, causing mmc_wait_for_request()
to fail. Thus, don't use __BUS_ACCESSOR() for mmcbr_get_retune_req() and
instead provide a version of the latter which returns retune_req_none if
reading MMCBR_IVAR_RETUNE_REQ fails.
Avoid printing extraneous function names when searching man page
database (apropos, man -k). This commit Replaces .SS with .SH,
similar to the man page provided by original heimdal (as in port).
Teach the EC2 AMI upload code to:
* Mark EBS snapshots as public,
* Announce new AMIs to an SNS topic, and
* Place the SVN branch and revision into the AMI "description".
eugen [Sat, 25 Aug 2018 10:42:44 +0000 (10:42 +0000)]
MFC 338013: bsnmpd(8): fix and optimize interface description processing
* correctly prepare a buffer to obtain interface description from a kernel
and truncate long description instead of dropping it altogether and
spamming logs;
* skip calling strlen() for each description and each SNMP request
for MIB-II/ifXTable's ifAlias.
* teach bsnmpd to allocate memory dynamically for interface descriptions
to decrease memory usage for common case and not to break
if long description occurs;
PR: 217763
Reviewed by: harti and others
Differential Revision: https://reviews.freebsd.org/D16459
rmacklem [Fri, 24 Aug 2018 22:48:19 +0000 (22:48 +0000)]
MFC: r337438
Allow newnfs_request() to retry all callback RPCs with an NFSERR_DELAY reply.
The code in newnfs_request() retries RPCs that get a reply of NFSERR_DELAY,
but exempts certain NFSv4 operations. However, for callback RPCs, there
should not be any exemptions at this time. The code would have erroneously
exempted the CBRECALL callback, since it has the same operation number as
the CLOSE operation.
This patch fixes this by checking for a callback RPC (indicated by clp != NULL)
and not checking for exempt operations for callbacks.
This would have only affected the NFSv4 server when delegations are enabled
(they are not enabled by default) and the client replies to CBRECALL with
NFSERR_DELAY. This may never actually happen.
Spotted during code inspection.
For use with things like BOOT_TAG=\"\" -- there are valid reasons to allow
empty strings, especially as these are usually being passed through as
options. The same argument could perhaps be made for the unquoted
variant in things like MODULES_OVERRIDE="", but it's not immediately clear
that this is an issue so I've left it untouched.
pfg [Wed, 22 Aug 2018 04:21:25 +0000 (04:21 +0000)]
MFC r337456:
msdosfs: fixes for Undefined Behavior.
These were found by the Undefined Behaviour GsoC project at NetBSD:
Do not change signedness bit with left shift.
While there avoid signed integer overflow.
Address both issues with using unsigned type.
msdosfs_fat.c:512:42, left shift of 1 by 31 places cannot be represented
in type 'int'
msdosfs_fat.c:521:44, left shift of 1 by 31 places cannot be represented
in type 'int'
msdosfs_fat.c:744:14, left shift of 1 by 31 places cannot be represented
in type 'int'
msdosfs_fat.c:744:24, signed integer overflow: -2147483648 - 1 cannot be
represented in type 'int [20]'
msdosfs_fat.c:840:13, left shift of 1 by 31 places cannot be represented
in type 'int'
msdosfs_fat.c:840:36, signed integer overflow: -2147483648 - 1 cannot be
represented in type 'int [20]'
cy [Wed, 22 Aug 2018 01:43:11 +0000 (01:43 +0000)]
MFC r338047:
The bucket index is subtracted by one at lines 2304 and 2314. When 0 it
becomes -1, except these are unsigned integers, so they become very large
numbers. Thus are always larger than the maximum bucket; the hash table
insertion fails causing NAT to fail.
This commit ensures that if the index is already zero it is not reduced
prior to insertion into the hash table.
cy [Wed, 22 Aug 2018 01:23:11 +0000 (01:23 +0000)]
MFC r338046:
Add handy DTrace probes useful in diagnosing NAT issues. DTrace probes
are situated next to error counters and/or in one instance prior to the
-1 return from various functions. This was useful in diagnosis of
PR/208566 and will be handy in the future diagnosing NAT failures.
cy [Wed, 22 Aug 2018 01:04:52 +0000 (01:04 +0000)]
MFC r338045:
Expose np (nat_t - an entry in the nat table structure) in the DTrace
probe when nat fails (label badnat). This is useful in diagnosing
failed NAT issues and was used in PR/208566.
rmacklem [Tue, 21 Aug 2018 11:17:25 +0000 (11:17 +0000)]
MFC: r336839
Modify the NFSv4.1 server so that it allows ReclaimComplete as done by ESXi 6.7.
I believe that a ReclaimComplete with rca_one_fs == TRUE is only
to be used after a file system has been transferred to a different
file server. However, RFC5661 is somewhat vague w.r.t. this and
the ESXi 6.7 client does both a ReclaimComplete with rca_one_fs == TRUE
and one with ReclaimComplete with rca_one_fs == FALSE.
Therefore, just ignore the rca_one_fs == TRUE operation and return
NFS_OK without doing anything instead of replying NFS4ERR_NOTSUPP.
This allows the ESXi 6.7 NFSv4.1 client to do a mount.
After discussion on the NFSv4 IETF working group mailing list, doing this
along with setting a flag to note that a ReclaimComplete with rca_one_fs TRUE
was an appropriate way to handle this.
The flag that indicates that a ReclaimComplete with rca_one_fs == TRUE was
done may be used to disable replies of NFS4ERR_GRACE for non-reclaim
state operations in a future commit.
This patch along with r332790, r334492 and r336357 allow ESXi 6.7 NFSv4.1 mounts
work ok. ESX 6.5 NFSv4.1 mounts do not work well, due to what I believe are
violations of RFC-5661 and should not be used.
cy [Tue, 21 Aug 2018 00:37:48 +0000 (00:37 +0000)]
MFC r337410:
Remove redundant and incorrect default definition of AF_INET6. AF_INET6
is defined in sys/socket.h where it's defined as 28.
A bit of trivia: On NetBSD AF_INET6 is defined as 24. On Solaris it is
defined as 26. This is probably why Darren defaulted to 26, because
ipfilter was originally written for SunOS 4 and Solaris many moons ago.
kp [Mon, 20 Aug 2018 15:43:08 +0000 (15:43 +0000)]
MFC r337969:
pf: Limit the maximum number of fragments per packet
Similar to the network stack issue fixed in r337782 pf did not limit the number
of fragments per packet, which could be exploited to generate high CPU loads
with a crafted series of packets.
Limit each packet to no more than 64 fragments. This should be sufficient on
typical networks to allow maximum-sized IP frames.
This addresses the issue for both IPv4 and IPv6.
Security: CVE-2018-5391
Sponsored by: Klara Systems
dim [Fri, 17 Aug 2018 06:31:30 +0000 (06:31 +0000)]
MFC r337322:
Fix build of hyperv with base gcc on i386
Summary:
Base gcc fails to compile `sys/dev/hyperv/pcib/vmbus_pcib.c` for i386,
with the following -Werror warnings:
cc1: warnings being treated as errors
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c: In function 'new_pcichild_device':
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c:567: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c: In function 'vmbus_pcib_on_channel_callback':
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c:940: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c: In function 'hv_pci_protocol_negotiation':
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c:1012: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c: In function 'hv_pci_enter_d0':
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c:1073: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c: In function 'hv_send_resources_allocated':
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c:1125: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c: In function 'vmbus_pcib_map_msi':
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c:1730: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
This is because on i386, several casts from `uint64_t` to a pointer
reduce the value from 64 bit to 32 bit.
For gcc, this can be fixed by an intermediate cast to uintptr_t. Note
that I am assuming the incoming values will always fit into 32 bit!
cy [Fri, 17 Aug 2018 02:46:36 +0000 (02:46 +0000)]
MFC r337558, r337560
r337558:
Identify the return value (rval) that led to the IPv4 NAT failure
in ipf_nat_checkout() and report it in the frb_natv4out and frb_natv4in
dtrace probes.
This is currently being used to diagnose NAT failures in PR/208566. It's
rather handy so this commit makes it available for future diagnosis and
debugging efforts.
PR: 208566
r337560:
Correct a comment. Should have been detected by ipf_nat_in() not
ipf_nat_out().
gjb [Thu, 16 Aug 2018 15:17:22 +0000 (15:17 +0000)]
MFC r337717, r337718:
r337717:
Add lang/python2, lang/python3, and lang/python to GCE images
to help avoid hard-coding 'python<MAJOR>.<MINOR>' in several
scripts in the client-side scripts. [1]
r337718:
Add a space between a variable and escaped new line.
PR: 230248 [1]
Sponsored by: The FreeBSD Foundation
brooks [Tue, 14 Aug 2018 16:25:09 +0000 (16:25 +0000)]
MFC r337508:
Terminate filter_create_ext() args with NULL, not 0.
filter_create_ext() is documented to take a NULL terminated set of
arguments. 0 is promoted to an int so this would fail on 64-bit
systems if the value was not passed in a register. On all currently
supported 64-bit architectures it is.
hselasky [Tue, 14 Aug 2018 11:44:11 +0000 (11:44 +0000)]
MFC r330657:
Use vport rather than physical-port MTU in mlx5en(4).
Set and report vport MTU rather than physical MTU,
The driver will set both vport and physical port mtu
and will rely on the query of vport mtu.
SRIOV VFs have to report their MTU to their vport manager (PF),
and this will allow them to work with any MTU they need
without failing the request.
Also for some cases where the PF is not a port owner, PF can
work with MTU less than the physical port mtu if set physical
port mtu didn't take effect.
hselasky [Tue, 14 Aug 2018 11:19:04 +0000 (11:19 +0000)]
MFC r336450:
Do not inline transmit headers and use HW VLAN tagging if supported by mlx5en(4).
Query the minimal inline mode supported by the card.
When creating a send queue, cache the queried mode and optimize the transmit
if no inlining is required. In this case, we can avoid touching the headers
cache line and avoid dirtying several more lines by copying headers into
the send WQEs. Also, if no inline headers are used, hardware assists in
the VLAN tag framing.
davidcs [Thu, 9 Aug 2018 01:39:47 +0000 (01:39 +0000)]
MFC r336695
Remove support for QLNX_RCV_IN_TASKQ - i.e., Rx only in TaskQ.
Added support for LLDP passthru
Upgrade ECORE to version 8.33.5.0
Upgrade STORMFW to version 8.33.7.0
davidcs [Thu, 9 Aug 2018 00:48:55 +0000 (00:48 +0000)]
MFC r336438
Fixes for the following issues:
1. Fix taskqueues drain/free to fix panic seen when interface is being
bought down and in parallel asynchronous link events happening.
2. Fix bxe_ifmedia_status()
Submitted by:Vaishali.Kulkarni@cavium.com and Anand.Khoje@cavium.com
jtl [Mon, 6 Aug 2018 17:46:28 +0000 (17:46 +0000)]
MFC r337384:
Address concerns about CPU usage while doing TCP reassembly.
Currently, the per-queue limit is a function of the receive buffer
size and the MSS. In certain cases (such as connections with large
receive buffers), the per-queue segment limit can be quite large.
Because we process segments as a linked list, large queues may not
perform acceptably.
The better long-term solution is to make the queue more efficient.
But, in the short-term, we can provide a way for a system
administrator to set the maximum queue size.
We set the default queue limit to 100. This is an effort to balance
performance with a sane resource limit. Depending on their
environment, goals, etc., an administrator may choose to modify this
limit in either direction.
Approved by: so
Security: FreeBSD-SA-18:08.tcp
Sponsored by: CVE-2018-6922
Relevant vendor changes:
Fix issue #948: out-of-bounds read in lha_read_data_none()
MFH r336854:
Sync libarchive with vendor.
Important vendor changes:
PR #993: Chdir to -C directory for metalog processing
OSS-Fuzz #4969: Check size of the extended time field in zip archives
PR #973: Record informational compression level in gzip header
asomers [Fri, 3 Aug 2018 14:45:53 +0000 (14:45 +0000)]
MFC r336205:
Don't acquire evclass_lock with a spinlock held
When the "pc" audit class is enabled and auditd is running, witness will
panic during thread exit because au_event_class tries to lock an rwlock
while holding a spinlock acquired upstack by thread_exit.
To fix this, move AUDIT_SYSCALL_EXIT futher upstack, before the spinlock is
acquired. Of thread_exit's 16 callers, it's only necessary to call
AUDIT_SYSCALL_EXIT from two, exit1 (for exiting processes) and kern_thr_exit
(for exiting threads). The other callers are all kernel threads, which
needen't call AUDIT_SYSCALL_EXIT because since they can't make syscalls
there will be nothing to audit. And exit1 already does call
AUDIT_SYSCALL_EXIT, making the second call in thread_exit redundant for that
case.
asomers [Fri, 3 Aug 2018 14:37:23 +0000 (14:37 +0000)]
MFC r335899:
auditd(8): register signal handlers interrutibly
auditd_wait_for_events() relies on read(2) being interrupted by signals,
but it registers signal handlers with signal(3), which sets SA_RESTART.
That breaks asynchronous signal handling. It means that signals don't
actually get handled until after an audit(8) trigger is received.
Symptoms include:
* Sending SIGTERM to auditd doesn't kill it right away; you must send
SIGTERM and then send a trigger with auditon(2).
* Same with SIGHUP
* Zombie child processes don't get reaped until auditd receives a trigger
sent by auditon. This includes children created by expiring audit trails
at auditd startup.
asomers [Fri, 3 Aug 2018 14:22:16 +0000 (14:22 +0000)]
MFC r334296:
Fix "Bad tailq" panic when auditing auditon(A_SETCLASS, ...)
Due to an oversight in r195280, auditon(A_SETCLASS, ...) would cause a tailq
element to get added to the tailq twice, resulting in a circular tailq. This
panics when INVARIANTS are on.
asomers [Fri, 3 Aug 2018 14:19:56 +0000 (14:19 +0000)]
MFC r330720:
tftpd: reject unknown opcodes
If tftpd receives a command with an unknown opcode, it simply exits 1. It
doesn't send an ERROR packet, and the client will hang waiting for one. Fix
it.
asomers [Fri, 3 Aug 2018 14:19:09 +0000 (14:19 +0000)]
MFC r330719:
tftpd: Abort on an WRQ access violation
On a WRQ (write request) tftpd checks whether the client has access
permission for the file in question. If not, then the write is prevented.
However, tftpd doesn't reply with an ERROR packet, nor does it abort.
Instead, it tries to receive the packet anyway.
The symptom is slightly different depending on the nature of the error. If
the target file is nonexistent and tftpd lacks permission to create it, then
tftpd will willingly receive the file, but not write it anywhere. If the
file exists but is not writable, then tftpd will fail to ACK to WRQ.
asomers [Fri, 3 Aug 2018 14:18:02 +0000 (14:18 +0000)]
MFC r330718:
tftpd: Verify world-writability for WRQ when using relative paths
tftpd(8) says that files may only be written if they already exist and are
publicly writable. tftpd.c verifies that a file is publicly writable if it
uses an absolute pathname. However, if the pathname is relative, that check
is skipped. Fix it.
Note that this is not a security vulnerability, because the transfer
ultimately doesn't work unless the file already exists and is owned by user
nobody. Also, this bug does not affect the default configuration, because
the default uses the "-s" option which makes all pathnames absolute.
asomers [Fri, 3 Aug 2018 14:17:11 +0000 (14:17 +0000)]
MFC r330710:
tftpd: Flush files as soon as they are fully received
On an RRQ, tftpd doesn't exit as soon as it's finished receiving a file.
Instead, it waits five seconds just in case the client didn't receive the
server's last ACK and decides to resend the final DATA packet.
Unfortunately, this created a 5 second delay from when the client thinks
it's done sending the file, and when the file is available for other
processes.
Fix this bug by closing the file as soon as receipt is finished.
PR: 157700
Reported by: Barry Mishler <barry_mishler@yahoo.com>
asomers [Fri, 3 Aug 2018 14:13:15 +0000 (14:13 +0000)]
MFC r330696, r330709, r330742, r331358
r330696:
Add some functional tests for tftpd(8)
tftpd(8) is difficult to test in isolation due to its relationship with
inetd. Create a test program that mimics the behavior of tftp(1) and
inetd(8) and verifies tftpd's response in several different scenarios.
These test cases cover all of the basic TFTP protocol, but not the optional
parts.
kib [Fri, 3 Aug 2018 14:12:37 +0000 (14:12 +0000)]
MFC r336683:
Extend ranges of the critical sections to ensure that context switch
code never sees FPU pcb flags not consistent with the hardware state.
asomers [Fri, 3 Aug 2018 14:08:39 +0000 (14:08 +0000)]
MFC r328266:
mlock(2): correct documentation for error conditions.
The man page is years out of date regarding errors. Our implementation _does_
allow unaligned addresses, and it _does_not_ check for negative lengths,
because the length is unsigned. It checks for overflow instead.
rmacklem [Wed, 1 Aug 2018 19:25:12 +0000 (19:25 +0000)]
MFC: r336357
Modify the reasons for not issuing a delegation in the NFSv4.1 server.
The ESXi NFSv4.1 client will generate warning messages when the reason for
not issuing a delegation is two. Two refers to a resource limit and I do
not see why it would be considered invalid. However it probably was not the
best choice of reason for not issuing a delegation.
This patch changes the reasons used to ones that the ESXi client doesn't
complain about. This change does not affect the FreeBSD client and does
not appear to affect behaviour of the Linux NFSv4.1 client.
RFC5661 defines these "reasons" but does not give any guidance w.r.t. which
ones are more appropriate to return to a client.
hselasky [Wed, 1 Aug 2018 11:08:52 +0000 (11:08 +0000)]
MFC r321686 and r330361:
Add inline functions to convert between sbintime_t and decimal time units.
Use them in some existing code that is vulnerable to roundoff errors.
hselasky [Wed, 1 Aug 2018 10:34:53 +0000 (10:34 +0000)]
MFC r330349 and r330362:
Allow pause_sbt() to catch signals during sleep by passing C_CATCH flag.
Define pause_sig() function macro helper similarly to other kernel functions
which catch signals. Update outdated function description.
Document pause_sig(9) and update prototypes for existing pause(9) and
pause_sbt(9) functions.
MFC: r336215
Ignore the cookie verifier for NFSv4.1 when the cookie is 0.
RFC5661 states that the cookie verifier should be 0 when the cookie is 0.
However, the wording is somewhat unclear and a recent discussion on the
nfsv4@ietf.org mailing list indicated that the NFSv4 server should ignore
the cookie verifier's value when the dirctory offset cookie is 0.
This patch deletes the check for this that would return NFSERR_BAD_COOKIE
when the verifier was not 0.
This was found during testing of the ESXi client against the NFSv4.1 server.
MFC: r335866
Fix the server side krpc so that the kernel nfsd threads terminate.
Occationally the kernel nfsd threads would not terminate when a SIGKILL
was posted for the kernel process (called nfsd (slave)). When this occurred,
the thread associated with the process (called "ismaster") had returned from
svc_run_internal() and was sleeping waiting for the other threads to terminate.
The other threads (created by kthread_start()) were still in svc_run_internal()
handling NFS RPCs.
The only way this could occur is for the "ismaster" thread to return from
svc_run_internal() without having called svc_exit().
There was only one place in the code where this could happen and this patch
stops that from happening.
Since the problem is intermittent, I cannot be sure if this has fixed the
problem, but I have not seen an occurrence of the problem with this patch
applied.
MFC: r334966
Add a couple of safety belt checks to the NFSv4.1 client related to sessions.
There were a couple of cases in newnfs_request() that it assumed that it
was an NFSv4.1 mount with a session. This should always be the case when
a Sequence operation is in the reply or the server replies NFSERR_BADSESSION.
However, if a server was broken and sent an erroneous reply, these safety
belt checks should avoid trouble.
The one check required a small tweak to nfsmnt_mdssession() so that it
returns NULL when there is no session instead of the offset of the field
in the structure (0x8 for i386).
This patch should have no effect on normal operation of the client.
Found by inspection during pNFS server development.
MFC: r334492
Add the BindConnectiontoSession operation to the NFSv4.1 server.
Under some fairly unusual circumstances, the Linux NFSv4.1 client is
doing a BindConnectiontoSession operation for TCP connections.
It is also used by the ESXi6.5 NFSv4.1 client.
This patch adds this operation to the NFSv4.1 server.
dab [Mon, 23 Jul 2018 18:47:04 +0000 (18:47 +0000)]
MFC r336457:
Make the definition of struct kevent in event.h match what the man page for kevent(2) says.
This is a trivial comment-only fix. The man page for kevent(2) gives
the definition of struct kevent, including a comment on each
field. The actual definition in sys/event.h omitted the comments on
some fields. Add the comments in. Not only does this make the man page
and include file agree, but the comments are useful in and of
themselves.
MFC: r333766
Add a missing nfsrv_freesession() call for an unlikely failure case.
Since NFSv4.1 clients normally create a single session which supports
both fore and back channels, it is unlikely that a callback will fail
due to a lack of a back channel.
However, if this failure occurred, the session wasn't being dereferenced
and would never be free'd.
Found by inspection during pNFS server development.
dim [Tue, 17 Jul 2018 21:10:31 +0000 (21:10 +0000)]
Pull in r211155 from upstream llvm trunk (by Tim Northover):
DAG: move sret demotion into most basic LowerCallTo implementation.
It looks like there are two versions of LowerCallTo here: the
SelectionDAGBuilder one is designed to operate on LLVM IR, and the
TargetLowering one in the case where everything is at DAG level.
Previously, only the SelectionDAGBuilder variant could handle
demoting an impossible return to sret semantics (before delegating to
the TargetLowering version), but this functionality is also useful
for certain libcalls (e.g. 128-bit operations on 32-bit x86). So
this commit moves the sret handling down a level.
This should fix "Call result #3 has unhandled type i32" errors when
building devel/libslang2 for i386. Direct commit to stable/10, since
clang 3.5 and later already have this change.
MFC: r333645
End grace for the NFSv4 server if all mounts do ReclaimComplete.
The NFSv4 protocol requires that the server only allow reclaim of state
and not issue any new open/lock state for a grace period after booting.
The NFSv4.0 protocol required this grace period to be greater than the
lease duration (over 2minutes). For NFSv4.1, the client tells the server
that it has done reclaiming state by doing a ReclaimComplete operation.
If all NFSv4 clients are NFSv4.1, the grace period can end once all the
clients have done ReclaimComplete, shortening the time period considerably.
This patch does this. If there are any NFSv4.0 mounts, the grace period
will still be over 2minutes.
This change is only an optimization and does not affect correct operation.
Detected on NetBSD:
# nm /usr/lib/libc.so|grep sanit
/public/src.git/lib/libc/citrus/modules/citrus_mapper_std.c:173:8:
runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
MFC: r333579
The NFSv4.1 server should return NFSERR_BACKCHANBUSY instead of NFS_OK.
When an NFSv4.1 session is busy due to a callback being in progress,
nfsrv_freesession() should return NFSERR_BACKCHANBUSY instead of NFS_OK.
The only effect this has is that the DestroySession operation will report
the failure for this case and this probably has little or no effect on a
client. Spotted by inspection and no failures related to this have been
reported.
dab [Wed, 11 Jul 2018 14:56:38 +0000 (14:56 +0000)]
MFC r335765, r335776, r336186:
Remove potential identifier conflict in the EV_SET macro.
PR43905 pointed out a problem with the EV_SET macro if the passed
struct kevent pointer were specified with an expression with side
effects (e.g., "kevp++"). This was fixed in rS110241, but by using a
local block that defined an internal variable (named "kevp") to get
the pointer value once. This worked, but could cause issues if an
existing variable named "kevp" is in scope. To avoid that issue,
jilles@ pointed out that "C99 compound literals and designated
initializers allow doing this cleanly using a macro". This change
incorporates that suggestion, essentially verbatim from jilles@
comment on PR43905, except retaining the old definition for pre-C99 or
non-STDC (e.g., C++) compilers.
MFC: r333508
Add support for the TestStateID operation to the NFSv4.1 server.
The Linux client now uses the TestStateID operation, so this patch adds
support for it to the NFSv4.1 server. The FreeBSD client never uses this
operation, so it should not be affected.
Allow jail names (not just IDs) to be specified for: cpuset(1), ipfw(8),
sockstat(1), ugidfw(8)
These are the last of the jail-aware userland utilities that didn't work
with names.
ian [Wed, 4 Jul 2018 14:12:09 +0000 (14:12 +0000)]
MFC r335575, r335786
r335575:
Use 'mv -f' in rc.d/ntpd to avoid spuriously halting the boot.
The final 'mv' to install a fetched leap-list file can fail (due to a
readonly fs, or schg flags, for example), and that leads to mv(1)
prompting the user, stopping the boot process. Instead, use mv -f
to supress the prompting, and if verbose mode is on, emit a warning
that the existing file cannot be replaced.
PR: 219255
r335786:
Rename variable ntp_tmp_leapfile to have a leading underbar, to distinguish
it from variables with similar names which are set in rc.conf. This will
make more sense as the script grows more similar-name local variables in
some upcoming changes.
ian [Wed, 4 Jul 2018 14:10:36 +0000 (14:10 +0000)]
MFC r335595-r335596
r335595:
Modernize usage of "restrict" keyword in ntp.conf
It is no longer necessary to specify a -4/-6 flag on any ntp.conf
keyword. The address type is inferred from the address itself as
necessary. "restrict default" statements always apply to both address
families regardless of any -4/-6 flag that may be present.
So this change just tidies up our default config by removing the redundant
restrict -6 statement and comment, and by removing the -6 flag from the
restrict keyword that allows access from localhost.
This change was inspired by the patches provided in PRs 201803 and 210245,
and included some contrib/ntp code inspection to verify that the -4/-6
keywords are basically no-ops in all contexts now.
r335596:
Fix a comment; the ntp leaplist file is updated periodically, but not weekly
(it's only updated when a check shows it's within 30 days of expiring).
humanize_number(3): fix math edge case in rounding large numbers
Fix for remainder overflow, when in rare cases adding remainder to divider
exceeded 1 and turned the total to 1000 in final formatting, taking up
the space for the unit character.
The fix continues the division of the original number if the above case
happens -- added the appropriate check to the for loop performing
the division. This lowers the value shown, to make it fit into the buffer
space provided (1.0M for 4+1 character buffer, as used by ls).
Add test case for the reported bug and extend test program to support
providing buffer length (ls -lh uses 5, tests hard-coded 4).
brooks [Thu, 28 Jun 2018 21:23:05 +0000 (21:23 +0000)]
MFC r335641:
Fix a stack overflow in mount_smbfs when hostname is too long.
The local hostname was blindly copied into the to the nn_name array.
When the hostname exceeded 16 bytes, it would overflow. Truncate the
hostname to 15 bytes plus a 0 terminator which is the "workstation name"
suffix.
Use defensive strlcpy() when filling nn_name in all cases.
PR: 228354
Reported by: donald.buchholz@intel.com
Reviewed by: jpaetzel, ian (prior version)
Discussed with: Security Officer (gtetlow)
Security: Stack overflow with the hostname.
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D15936