the modes and flags. Document the structure fields properly.
Distinguish internals from public interfaces. Mention historic dead
flags like SAVESTART because they still exist in other projects.
Explain the current layout of vfs_lookup.c, or at least the primary
points of it.
Etc.
This ended up being a much larger rewrite than I intended.
Bump date again.
1) ACPICA kernel-resident subsystem:
Fixed a regression in the GAS (generic address structure) arbitrary bit
support in AcpiHwRead/AcpiHwWrite. Problem could cause incorrect behavior
and incorrect return values. Lv Zheng. ACPICA BZ 1270.
ACPI 6.0: Added support for new/renamed resource macros. One new argument
was added to each of these macros, and the original name has been
deprecated. The AML disassembler will always disassemble to the new
names. Support for the new macros was added to iASL, disassembler,
resource manager, and the acpihelp utility. ACPICA BZ 1274.
I2cSerialBus -> I2cSerialBusV2
SpiSerialBus -> SpiSerialBusV2
UartSerialBus -> UartSerialBusV2
ACPI 6.0: Added support for a new integer field that was appended to the
package object returned by the _BIX method. This adds iASL compile-time
and AML runtime error checking. ACPICA BZ 1273.
ACPI 6.1: Added support for a new PCCT subtable, "HW-Reduced Comm
Subspace Type2" (Headers, Disassembler, and data table compiler).
Example Code and Data Size: These are the sizes for the OS-independent
acpica.lib produced by the Microsoft Visual C++ 9.0 32-bit compiler. The
debug version of the code includes the debug output trace mechanism and
has a much larger code and data size.
Current Release:
Non-Debug Version: 137.4K Code, 52.6K Data, 190.0K Total
Debug Version: 201.5K Code, 82.2K Data, 283.7K Total
Previous Release:
Non-Debug Version: 137.1K Code, 51.5K Data, 188.6K Total
Debug Version: 201.0K Code, 82.0K Data, 283.0K Total
2) iASL Compiler/Disassembler and Tools:
iASL: Implemented an ASL grammar extension to allow/enable executable
"module-level code" to be created and executed under the various
operators that create new scopes. This type of AML code is already
supported in all known AML interpreters, and the grammar change will
appear in the next version of the ACPI specification. Simplifies the
conditional runtime creation of named objects under these object types:
Device
PowerResource
Processor
Scope
ThermalZone
iASL: Implemented a new ASL extension, a "For" loop macro to add greater
ease-of-use to the ASL language. The syntax is similar to the
corresponding C operator, and is implemented with the existing AML While
opcode -- thus requiring no changes to existing AML interpreters.
For (Initialize, Predicate, Update) {TermList}
Grammar:
ForTerm :=
For (
Initializer // Nothing | TermArg => ComputationalData
Predicate // Nothing | TermArg => ComputationalData
Update // Nothing | TermArg => ComputationalData
) {TermList}
iASL: The _HID/_ADR detection and validation has been enhanced to search
under conditionals in order to allow these objects to be conditionally
created at runtime.
iASL: Fixed several issues with the constant folding feature. The
improvement allows better detection and resolution of statements that can
be folded at compile time. ACPICA BZ 1266.
iASL/Disassembler: Fixed a couple issues with the Else{If{}...}
conversion to the ASL ElseIf operator where incorrect ASL code could be
generated.
iASL/Disassembler: Fixed a problem with the ASL+ code disassembly where
sometimes an extra (and extraneous) set of parentheses were emitted for
some combinations of operators. Although this did not cause any problems
with recompilation of the disassembled code, it made the code more
difficult to read. David Box. ACPICA BZ 1231.
iASL: Changed to ignore the unreferenced detection for predefined names
of resource descriptor elements, when the resource descriptor is
created/defined within a control method.
iASL: Disassembler: Fix a possible fault with externally declared Buffer
objects.
----------------------------------------
18 March 2016. Summary of changes for version 20160318:
1) ACPICA kernel-resident subsystem:
Added support for arbitrary bit lengths and bit offsets for registers
defined by the Generic Address Structure. Previously, only aligned bit
lengths of 8/16/32/64 were supported. This was sufficient for many years,
but recently some machines have been seen that require arbitrary bit-
level support. ACPICA BZ 1240. Lv Zheng.
Fixed an issue where the \_SB._INI method sometimes must be evaluated
before any _REG methods are evaluated. Lv Zheng.
Implemented several changes related to ACPI table support
(Headers/Disassembler/TableCompiler):
NFIT: For ACPI 6.1, updated to add some additional new fields and
constants.
FADT: Updated a warning message and set compliance to ACPI 6.1 (Version
6).
DMAR: Added new constants per the 10/2014 DMAR spec.
IORT: Added new subtable per the 10/2015 IORT spec.
HEST: For ACPI 6.1, added new constants and new subtable.
DBG2: Added new constants per the 12/2015 DBG2 spec.
FPDT: Fixed several incorrect fields, add the FPDT boot record structure.
ACPICA BZ 1249.
ERST/EINJ: Updated disassembler with new "Execute Timings" actions.
Updated header support for the DMAR table to match the current version of
the related spec.
Added extensions to the ASL Concatenate operator to allow any ACPI object
to be passed as an operand. Any object other than Integer/String/Buffer
simply returns a string containing the object type. This extends the
usefulness of the Printf macros. Previously, Concatenate would abort the
control method if a non-data object was encountered.
ACPICA source code: Deployed the C "const" keyword across the source code
where appropriate. ACPICA BZ 732. Joerg Sonnenberger (NetBSD).
Example Code and Data Size: These are the sizes for the OS-independent
acpica.lib produced by the Microsoft Visual C++ 9.0 32-bit compiler. The
debug version of the code includes the debug output trace mechanism and
has a much larger code and data size.
Current Release:
Non-Debug Version: 137.1K Code, 51.5K Data, 188.6K Total
Debug Version: 201.0K Code, 82.0K Data, 283.0K Total
Previous Release:
Non-Debug Version: 136.2K Code, 51.5K Data, 187.7K Total
Debug Version: 200.4K Code, 82.0K Data, 282.4K Total
2) iASL Compiler/Disassembler and Tools:
iASL/Disassembler: Improved the heuristic used to determine the number of
arguments for an externally defined control method (a method in another
table). Although this is an improvement, there is no deterministic way to
"guess" the number of method arguments. Only the ACPI 6.0 External opcode
will completely solve this problem as it is deployed (automatically) in
newer BIOS code.
iASL/Disassembler: Fixed an ordering issue for emitted External() ASL
statements that could cause errors when the disassembled file is
compiled. ACPICA BZ 1243. David Box.
iASL: Fixed a regression caused by the merger of the two versions of the
local strtoul64. Because of a dependency on a global variable, strtoul64
could return an error for integers greater than a 32-bit value. ACPICA BZ
1260.
iASL: Fixed a regression where a fault could occur for an ASL Return
statement if it invokes a control method that is not resolved. ACPICA BZ
1264.
AcpiXtract: Improved input file validation: detection of binary files and
non-acpidump text files.
----------------------------------------
12 February 2016. Summary of changes for version 20160212:
1) ACPICA kernel-resident subsystem:
Implemented full support for the ACPI 6.1 specification (released in
January). This version of the specification is available at:
http://www.uefi.org/specifications
Only a relatively small number of changes were required in ACPICA to
support ACPI 6.1, in these areas:
- New predefined names
- New _HID values
- A new subtable for HEST
- A few other header changes for new values
Ensure \_SB_._INI is executed before any _REG methods are executed. There
appears to be existing BIOS code that relies on this behavior. Lv Zheng.
Reverted a change made in version 20151218 which enabled method
invocations to be targets of various ASL operators (SuperName and Target
grammar elements). While the new behavior is supported by the ACPI
specification, other AML interpreters do not support this behavior and
never will. The ACPI specification will be updated for ACPI 6.2 to remove
this support. Therefore, the change was reverted to the original ACPICA
behavior.
ACPICA now supports the GCC 6 compiler.
Current Release: (Note: build changes increased sizes)
Non-Debug Version: 136.2K Code, 51.5K Data, 187.7K Total
Debug Version: 200.4K Code, 82.0K Data, 282.4K Total
Previous Release:
Non-Debug Version: 102.7K Code, 28.4K Data, 131.1K Total
Debug Version: 200.4K Code, 81.9K Data, 282.3K Total
2) iASL Compiler/Disassembler and Tools:
Completed full support for the ACPI 6.0 External() AML opcode. The
compiler emits an external AML opcode for each ASL External statement.
This opcode is used by the disassembler to assist with the disassembly of
external control methods by specifying the required number of arguments
for the method. AML interpreters do not use this opcode. To ensure that
interpreters do not even see the opcode, a block of one or more external
opcodes is surrounded by an "If(0)" construct. As this feature becomes
commonly deployed in BIOS code, the ability of disassemblers to correctly
disassemble AML code will be greatly improved. David Box.
iASL: Implemented support for an optional cross-reference output file.
The -lx option will create a the cross-reference file with the suffix
"xrf". Three different types of cross-reference are created in this file:
- List of object references made from within each control method
- Invocation (caller) list for each user-defined control method
- List of references to each non-method object in the namespace
iASL: Method invocations as ASL Target operands are now disallowed and
flagged as errors in preparation for ACPI 6.2 (see the description of the
problem above).
_GNU_SOURCE to be defined for systems that need it (like glibc ones.)
be sure to find the right config.h for host programs.
these fixes combined make builds on debian 7 complete for me.
Many of the global configuration parameters are written as strings
without filtering and if there is an embedded newline character in the
value, unexpected configuration file data might be written.
This fixes an issue where wpa_supplicant could have updated the
configuration file global parameter with arbitrary data from the control
interface or D-Bus interface. While those interfaces are supposed to be
accessible only for trusted users/applications, it may be possible that
an untrusted user has access to a management software component that
does not validate the value of a parameter before passing it to
wpa_supplicant.
This could allow such an untrusted user to inject almost arbitrary data
into the configuration file. Such configuration file could result in
wpa_supplicant trying to load a library (e.g., opensc_engine_path,
pkcs11_engine_path, pkcs11_module_path, load_dynamic_eap) from user
controlled location when starting again. This would allow code from that
library to be executed under the wpa_supplicant process privileges.
Most of the cred block parameters are written as strings without
filtering and if there is an embedded newline character in the value,
unexpected configuration file data might be written.
This fixes an issue where wpa_supplicant could have updated the
configuration file cred parameter with arbitrary data from the control
interface or D-Bus interface. While those interfaces are supposed to be
accessible only for trusted users/applications, it may be possible that
an untrusted user has access to a management software component that
does not validate the credential value before passing it to
wpa_supplicant.
This could allow such an untrusted user to inject almost arbitrary data
into the configuration file. Such configuration file could result in
wpa_supplicant trying to load a library (e.g., opensc_engine_path,
pkcs11_engine_path, pkcs11_module_path, load_dynamic_eap) from user
controlled location when starting again. This would allow code from that
library to be executed under the wpa_supplicant process privileges.
Spurious newlines output while writing the config file can corrupt the
wpa_supplicant configuration. Avoid writing these for the network block
parameters. This is a generic filter that cover cases that may not have
been explicitly addressed with a more specific commit to avoid control
characters in the psk parameter.
WPA/WPA2-Personal passphrase is not allowed to include control
characters. Reject a passphrase configuration attempt if that passphrase
includes an invalid passphrase.
This fixes an issue where wpa_supplicant could have updated the
configuration file psk parameter with arbitrary data from the control
interface or D-Bus interface. While those interfaces are supposed to be
accessible only for trusted users/applications, it may be possible that
an untrusted user has access to a management software component that
does not validate the passphrase value before passing it to
wpa_supplicant.
This could allow such an untrusted user to inject up to 63 characters of
almost arbitrary data into the configuration file. Such configuration
file could result in wpa_supplicant trying to load a library (e.g.,
opensc_engine_path, pkcs11_engine_path, pkcs11_module_path,
load_dynamic_eap) from user controlled location when starting again.
This would allow code from that library to be executed under the
wpa_supplicant process privileges.
WPA/WPA2-Personal passphrase is not allowed to include control
characters. Reject a Credential received from a WPS Registrar both as
STA (Credential) and AP (AP Settings) if the credential is for WPAPSK or
WPA2PSK authentication type and includes an invalid passphrase.
This fixes an issue where hostapd or wpa_supplicant could have updated
the configuration file PSK/passphrase parameter with arbitrary data from
an external device (Registrar) that may not be fully trusted. Should
such data include a newline character, the resulting configuration file
could become invalid and fail to be parsed.
*) Prevent padding oracle in AES-NI CBC MAC check
A MITM attacker can use a padding oracle attack to decrypt traffic
when the connection uses an AES CBC cipher and the server support
AES-NI.
This issue was introduced as part of the fix for Lucky 13 padding
attack (CVE-2013-0169). The padding check was rewritten to be in
constant time by making sure that always the same bytes are read and
compared against either the MAC or padding bytes. But it no longer
checked that there was enough data to have both the MAC and padding
bytes.
This issue was reported by Juraj Somorovsky using TLS-Attacker.
(CVE-2016-2107)
[Kurt Roeckx]
*) Fix EVP_EncodeUpdate overflow
An overflow can occur in the EVP_EncodeUpdate() function which is used for
Base64 encoding of binary data. If an attacker is able to supply very large
amounts of input data then a length check can overflow resulting in a heap
corruption.
Internally to OpenSSL the EVP_EncodeUpdate() function is primarly used by
the PEM_write_bio* family of functions. These are mainly used within the
OpenSSL command line applications, so any application which processes data
from an untrusted source and outputs it as a PEM file should be considered
vulnerable to this issue. User applications that call these APIs directly
with large amounts of untrusted data may also be vulnerable.
This issue was reported by Guido Vranken.
(CVE-2016-2105)
[Matt Caswell]
*) Fix EVP_EncryptUpdate overflow
An overflow can occur in the EVP_EncryptUpdate() function. If an attacker
is able to supply very large amounts of input data after a previous call to
EVP_EncryptUpdate() with a partial block then a length check can overflow
resulting in a heap corruption. Following an analysis of all OpenSSL
internal usage of the EVP_EncryptUpdate() function all usage is one of two
forms. The first form is where the EVP_EncryptUpdate() call is known to be
the first called function after an EVP_EncryptInit(), and therefore that
specific call must be safe. The second form is where the length passed to
EVP_EncryptUpdate() can be seen from the code to be some small value and
therefore there is no possibility of an overflow. Since all instances are
one of these two forms, it is believed that there can be no overflows in
internal code due to this problem. It should be noted that
EVP_DecryptUpdate() can call EVP_EncryptUpdate() in certain code paths.
Also EVP_CipherUpdate() is a synonym for EVP_EncryptUpdate(). All instances
of these calls have also been analysed too and it is believed there are no
instances in internal usage where an overflow could occur.
This issue was reported by Guido Vranken.
(CVE-2016-2106)
[Matt Caswell]
*) Prevent ASN.1 BIO excessive memory allocation
When ASN.1 data is read from a BIO using functions such as d2i_CMS_bio()
a short invalid encoding can casuse allocation of large amounts of memory
potentially consuming excessive resources or exhausting memory.
Any application parsing untrusted data through d2i BIO functions is
affected. The memory based functions such as d2i_X509() are *not* affected.
Since the memory based functions are used by the TLS library, TLS
applications are not affected.
This issue was reported by Brian Carpenter.
(CVE-2016-2109)
[Stephen Henson]
*) EBCDIC overread
ASN1 Strings that are over 1024 bytes can cause an overread in applications
using the X509_NAME_oneline() function on EBCDIC systems. This could result
in arbitrary stack data being returned in the buffer.
This issue was reported by Guido Vranken.
(CVE-2016-2176)
[Matt Caswell]
*) Modify behavior of ALPN to invoke callback after SNI/servername
callback, such that updates to the SSL_CTX affect ALPN.
[Todd Short]
*) Remove LOW from the DEFAULT cipher list. This removes singles DES from the
default.
[Kurt Roeckx]
*) Only remove the SSLv2 methods with the no-ssl2-method option. When the
methods are enabled and ssl2 is disabled the methods return NULL.
[Kurt Roeckx]
This allows anything that could be a filesystem command to be
implemented as a function instead. The restriction on '/'
is because of the way that functions are (required to be) searched
for relative to PATH searching - a function with a name containing '/'
could never be executed, so simply prohibit defining such a thing.
ok christos@
snj