The single-letter variables 't', 's', 'l' and 'c' were too hard to
decipher.
The variable 'f_len' was used for two independent purposes.
Use a narrow scope for some variables, to avoid having to keep track of
22 individual variables at the same time.
No binary change.
Remove redundant parentheses and casts.
Indent statement-like macros consistently, use separate lines for each
statement, add parentheses to macro definitions.
Remove CONSTCOND comments as lint doesn't need them anymore.
No binary change.
Due to the check that any bytes beyond the expected output must be
unmodified, there's no need anymore to explicitly write the "ZZZ" at the
end of the expected output. While here, remove the redundant trailing
"\0".
Add more tests to cover possible situations where an out-of-bounds write
may have occurred. In some cases, the line length specified in
snprintb_m is exceeded.
In the previous commit, I had accidentally only run the tests for
snprintb_m but not those for snprintb, thereby missing a newly
introduced bug that would not null-terminate the resulting strings.
Add more tests to cover similar situations in which the buffer is too
small to contain the complete output.
ignore differences in the install target flag - the backend might have
flipped it off already to ensure only a single partition is marked
as install target.
https://www.top10vpn.com/research/wifi-vulnerabilities/
PEAP client: Update Phase 2 authentication requirements
The previous PEAP client behavior allowed the server to skip Phase 2
authentication with the expectation that the server was authenticated
during Phase 1 through TLS server certificate validation. Various PEAP
specifications are not exactly clear on what the behavior on this front
is supposed to be and as such, this ended up being more flexible than
the TTLS/FAST/TEAP cases. However, this is not really ideal when
unfortunately common misconfiguration of PEAP is used in deployed
devices where the server trust root (ca_cert) is not configured or the
user has an easy option for allowing this validation step to be skipped.
Change the default PEAP client behavior to be to require Phase 2
authentication to be successfully completed for cases where TLS session
resumption is not used and the client certificate has not been
configured. Those two exceptions are the main cases where a deployed
authentication server might skip Phase 2 and as such, where a more
strict default behavior could result in undesired interoperability
issues. Requiring Phase 2 authentication will end up disabling TLS
session resumption automatically to avoid interoperability issues.
Allow Phase 2 authentication behavior to be configured with a new phase1
configuration parameter option:
'phase2_auth' option can be used to control Phase 2 (i.e., within TLS
tunnel) behavior for PEAP:
* 0 = do not require Phase 2 authentication
* 1 = require Phase 2 authentication when client certificate
(private_key/client_cert) is no used and TLS session resumption was
not used (default)
* 2 = require Phase 2 authentication in all cases
To keep its cache database efficient, `named` running as a recursive
resolver occasionally attempts to clean up the database. It uses
several methods, including some that are asynchronous: a small
chunk of memory pointing to the cache element that can be cleaned
up is first allocated and then queued for later processing. It was
discovered that if the resolver is continuously processing query
patterns triggering this type of cache-database maintenance, `named`
may not be able to handle the cleanup events in a timely manner.
This in turn enables the list of queued cleanup events to grow
infinitely large over time, allowing the configured `max-cache-size`
limit to be significantly exceeded. This issue affects BIND 9
versions 9.16.0 through 9.16.45 and 9.16.8-S1 through 9.16.45-S1.
A bad interaction between DNS64 and serve-stale may cause `named`
to crash with an assertion failure during recursive resolution,
when both of these features are enabled. This issue affects BIND
9 versions 9.16.12 through 9.16.45, 9.18.0 through 9.18.21, 9.19.0
through 9.19.19, 9.16.12-S1 through 9.16.45-S1, and 9.18.11-S1
through 9.18.21-S1.
A flaw in query-handling code can cause `named` to exit prematurely
with an assertion failure when: - `nxdomain-redirect <domain>;` is
configured, and - the resolver receives a PTR query for an RFC 1918
address that would normally result in an authoritative NXDOMAIN
response. This issue affects BIND 9 versions 9.12.0 through 9.16.45,
9.18.0 through 9.18.21, 9.19.0 through 9.19.19, 9.16.8-S1 through
9.16.45-S1, and 9.18.11-S1 through 9.18.21-S1.
The DNS message parsing code in `named` includes a section whose
computational complexity is overly high. It does not cause problems
for typical DNS traffic, but crafted queries and responses may
cause excessive CPU load on the affected `named` instance by
exploiting this flaw. This issue affects both authoritative servers
and recursive resolvers. This issue affects BIND 9 versions 9.0.0
through 9.16.45, 9.18.0 through 9.18.21, 9.19.0 through 9.19.19,
9.9.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.45-S1, and
9.18.11-S1 through 9.18.21-S1.
My own MegaRAID 946N-8i 2G", firmware 50.5.0-2594 failed to attach.
mfii0: unknown firmware state 1879048192
1879048192 equals to 0x70000000(== MFI_STATE_FW_INIT_2).
Apply following two OpenBSD commits to resolve this problem.
----------------------------
sys/dev/pci/mfii.c OpenBSD rev. 1.86
sys/dev/ic/mfireg.h OpenBSD rev. 1.52
Make mfii(4) recover from firmware FAULT state on startup.
In case firmware initially comes up in FAULT state, reset the device and
give it one more chance to attach successfully. The Linux megaraid_sas
driver applies the same workaround in this case. There seems to be a bug
in some firmware versions which can trigger this behaviour; see mainline
Linux commit 6431f5d7c6025f8b007af06ea090de308f7e6881
Problem observed by me with mfii(4) attached via KVM PCI-passthrough:
mfii0 at pci0 dev 2 function 0 "Symbios Logic MegaRAID SAS2208" rev 0x05: msi
mfii0: firmware fault
With this workaround in place, attachment succeeds and the device works:
mfii0 at pci0 dev 2 function 0 "Symbios Logic MegaRAID SAS2208" rev 0x05: msi
mfii0: firmware fault; attempting full device reset, this can take some time
mfii0: "RAID Ctrl SAS 6G 1GB (D3116C)", firmware 23.29.0-0019, 1024MB cache
Tested for regressions on bare metal by Hrvoje with two different adapters:
mfii0 at pci1 dev 0 function 0 "Symbios Logic MegaRAID SAS3508" rev 0x01: msi
mfii0: "PERC H740P Mini ", firmware 51.16.0-4076, 8192MB cache
mfii0 at pci4 dev 0 function 0 "Symbios Logic MegaRAID SAS2208" rev 0x05: msi
mfii0: "ServeRAID M5110", firmware 23.34.0-0023, 512MB cache
ok jmatthew@
----------------------------
sys/dev/pci/mfii.c OpenBSD rev. 1.87
Give mfii(4) firmware more time to transition out of UNDEFINED state.
Prevents occasional failure to recover from firmware FAULT state where
the driver gave up too early: mfii0: firmware stuck in state 0
ok deraadt@
skrll