We can have in a register an address that points to/into some variable
in the data segment, but db_print_loc_and_inst only looks for
functions, so it will misprint it as something unrelated from libkern
+ huge offset. E.g. instead of netbsd:cpu_info_store it would print
netbsd:prop_string_create_cstring+0xdeadbeef
Worse, if the address happens to be odd (char field in a struct, an
element of char array), attempt at printing the "instruction" at that
address will cause a fault and will abort "mach frame".
Disassemly is not really that useful in "mach frame" listing anyway
and more often just clutters things by overflowing 80 columns.
* Assertion failure in ISC BIND SIG query processing (CVE-2006-4095)
- Recursive servers
Queries for SIG records will trigger an assertion failure if more
than one RRset is returned. However exposure can be minimized by
restricting which sources can ask for recursion.
- Authoritative servers
If a nameserver is serving a RFC 2535 DNSSEC zone and is queried
for the SIG records where there are multiple RRsets, then the
named program will trigger an assertion failure when it tries
to construct the response.
* INSIST failure in ISC BIND recursive query handling code (CVE-2006-4096)
It is possible to trigger an INSIST failure by sending enough
recursive queries such that the response to the query arrives after
all the clients waiting for the response have left the recursion
queue. However exposure can be minimized by restricting which sources
can ask for recursion.
ok'ed christos@
First one was incorrectly loading entries -- we were treating each file as
a mount, which resulted in huge mess. I have no excuse for how I didn't
catch this earlier.
Second, use the table name we create for the Veriexec sysctl node and not
the fixed "table0".
Both are fileassoc(9) integration fallout.
Daniel Bleichenbacher recently described an attack on PKCS #1 v1.5
signatures. If an RSA key with exponent 3 is used it may be possible
to forge a PKCS #1 v1.5 signature signed by that key. Implementations
may incorrectly verify the certificate if they are not checking for
excess data in the RSA exponentiation result of the signature.
Since there are CAs using exponent 3 in wide use, and PKCS #1 v1.5 is
used in X.509 certificates, all software that uses OpenSSL to verify
X.509 certificates is potentially vulnerable, as well as any other use
of PKCS #1 v1.5. This includes software that uses OpenSSL for SSL or
TLS.
Dreamcast does not use SuperH on-chip RTC, so do it seprately from
other sh3 ports. Convert dreamcast rtc code into a real device
instead of searching/attaching it manually.
Tested by Nick Hudson.
unsigned for now. This prevents rf_reasonable_label() from rejecting
a valid label when these fields have an integer overflow. The reality
is that these need to be 64-bit quantities, but that will come later.
