sec-updater checks for security updates and backports in Debian/
Ubuntu repositories and sets the security flags in the strongTNC
policy database accordingly.
If an interface is renamed we already have an entry (based on the
ifindex) allocated but previously only set the usable state once
based on the original name.
Fixes#2403.
There is a bug in some versions of lcov that causes it to fail writing
to files via relative paths after it issued warnings (e.g. due to
negative counts in the tracefile).
The generic field of size 0 in the union that was used previously
triggered index-out-of-bounds errors with the UBSAN sanitizer that's
used on OSS-Fuzz. Since the two family specific union members don't
really provide any advantage, we can just use a single buffer for both
families to avoid the errors.
By definition, m must be <= n-1, we didn't enforce that and because
mpz_export() returns NULL if the passed value is zero a crash could have
been triggered with m == n.
Fixes CVE-2017-11185.
When querying SAs the keys will end up in this buffer (the allocated
messages that are returned are already wiped). The kernel also returns
XFRM_MSG_NEWSA as response to XFRM_MSG_ALLOCSPI but we can't distinguish
this here as we only see the response.
References #2388.
When requiring unique flags for CHILD_SAs, allow the configuration to
request different marks for each direction by using the %unique-dir keyword.
This is useful when different marks are desired for each direction but the
number of peers is not predefined.
An example use case is when implementing a site-to-site route-based VPN
without VTI devices.
A use of 0.0.0.0/0 - 0.0.0.0/0 traffic selectors with identical in/out marks
results in outbound traffic being wrongfully matched against the 'fwd'
policy - for which the underlay 'template' does not match - and dropped.
Using different marks for each direction avoids this issue as the 'fwd' policy
uses the 'in' mark will not match outbound traffic.
Closesstrongswan/strongswan#78.
Initiation might later fail, of course, but we don't really
require an IP address when installing, that is, unless the remote
traffic selector is dynamic. As that would result in installing a
0.0.0.0/0 remote TS which is not ideal when a single IP is expected as
remote.
Tobias Brunner