Changes between 1.1.1m and 1.1.1n [15 Mar 2022]
*) Fixed a bug in the BN_mod_sqrt() function that can cause it to loop forever
for non-prime moduli.
Internally this function is used when parsing certificates that contain
elliptic curve public keys in compressed form or explicit elliptic curve
parameters with a base point encoded in compressed form.
It is possible to trigger the infinite loop by crafting a certificate that
has invalid explicit curve parameters.
Since certificate parsing happens prior to verification of the certificate
signature, any process that parses an externally supplied certificate may
thus be subject to a denial of service attack. The infinite loop can also
be reached when parsing crafted private keys as they can contain explicit
elliptic curve parameters.
Thus vulnerable situations include:
- TLS clients consuming server certificates
- TLS servers consuming client certificates
- Hosting providers taking certificates or private keys from customers
- Certificate authorities parsing certification requests from subscribers
- Anything else which parses ASN.1 elliptic curve parameters
Also any other applications that use the BN_mod_sqrt() where the attacker
can control the parameter values are vulnerable to this DoS issue.
(CVE-2022-0778)
[Tomáš Mráz]
*) Add ciphersuites based on DHE_PSK (RFC 4279) and ECDHE_PSK (RFC 5489)
to the list of ciphersuites providing Perfect Forward Secrecy as
required by SECLEVEL >= 3.
[Dmitry Belyavskiy, Nicola Tuveri]
Now that tun_lock runs at IPL_NONE, taking it does not have the side
effect of disabling preemption, but pktq_enqueue assumes the caller
has disabled preemption so it can safely schedule a softint.
This isn't a problem in most physical network drivers because the
pktq_enqueue call happens from within the driver's softint context
anyway. But tun(4) is special -- here, the pktq_enqueue is triggered
by a userland write to the device, which is in thread context. So
let's just disable preemption in tunwrite.
Reported-by: syzbot+21c2cb300f1ec2162b35@syzkaller.appspotmail.com
Changes by me:
- Minor style nits.
- Set errno on posix_spawn failure.
- Handle edge cases of SIGINT/SIGQUIT set to SIG_IGN by caller.
Author: Nikita Ronja Gillmann <nikita@NetBSD.org>
Committer: Taylor R Campbell <riastradh@NetBSD.org>
The warning is wrong, and it has been for a long time. For now just fix
the test to match the actual output. Seen on evbarm, which is one of
the platforms where a plain char is unsigned.
Noticed by Martin.
The standard says:
Transitional devices MUST have a PCI Revision ID of 0.
Non-transitional devices SHOULD have a PCI Revision ID of 1 or higher.
Drivers MUST match any PCI Revision ID value.
so we must not check the revision id for non-transitional devices.
The code in attach relies on the revision being specifically(NB!) 1 so
this calls for a revision, but I can't test this properly at the
moment, so just leave a reminder. Comment change only.
This adds a small overhead to the syscall path, but only when invoked
via the syscall(2) syscall, for which stack traces generally don't
print the actual syscall number in question so the better attribution
may make a difference.
Won't affect anything on x86 because atomic r/m/w operations are
always full sequential consistency barriers, but might potentially
fix problems on, e.g., arm.
Note 1: I'm not clear on why the track lock is a bespoke mutex made
out of an atomic -- why not just mutex(9)?
Note 2: I'm not convinced the audio_mlog_flush synchronization is
correct; what happens if the softint runs on two CPUs at the same
time and swaps mlog_wpage simultaneously?
Note 3: Should maybe use atomic_load/store_relaxed for mlog_full and
mlog_drop, and atomic_inc/dec for mlog_refs.
This is never taken from hardware interrupt handlers any more, as far
as I can tell -- only SOFTINT_NET soft interrupt handlers.
This avoids trying to take an adaptive lock, proc_lock, in fownsignal
while holding a spin lock. Unfortunately, it doesn't entirely fix the
problem -- proc_lock is at IPL_NONE, and is held across some not
entirely trivial computations like allocating a new pid table. So it
would really be better if we had some way to deliver SIGIO without
taking proc_lock.
Reported-by: syzbot+3dd54993d3e92e697e72@syzkaller.appspotmail.com
Reported-by: syzbot+aca29415f2f0bf23f082@syzkaller.appspotmail.com
Triggered by
clock_settime({.tv_sec=0, .tv_nsec=0})
clock_nanosleep({.tv_sec=LLONG_MIN, .tv_nsec=0})
so that, by the time we enter ts2timo (after a few nanoseconds have
passed), we end up with
tsd = {.tv_sec=0, .tv_nsec=nonzero}
ts = {.tv_sec=LLONG_MIN, .tv_nsec=0}
and the subtraction ts - tsd leads to a borrow from tv_sec.
Reported-by: syzbot+14818113e9d0b45bca64@syzkaller.appspotmail.com
Only print the heading for the symbol table level if there is actually a
symbol on that level.
Ensure that no symbol with block level -1 is ever in the symbol table
(see rmsym).
yamaguchi