Tor Browser: update to 15.0.22
basically a noop because Tor Browser 15.0.22 just updates Tor,
which for us is not bundled but provided through net/tor.
Fix a logic error in post_bl() that could cause a NULL pointer access.
When a column list does not use explicit .It macros and contains
at least one text line followed by a node generated on the roff(7)
level, for example an eqn(7) node, and then nothing more, in
particular no following .It macro, the code wraps the node generated
on the roff level in an implicit .It macro. After moving the node
into the new .It macro, the loop variable "nchild" iterating over
the children of .Bl must be set to NULL to exit the while loop.
Instead, the loop variable remained pointing at the moved node, and
the loop tried to move it again, resulting in an access to its
"prev" pointer, which is of course NULL in this situation.
Hippolyte Doncieu de la Batie <hippolyte.doncieu at gmail.com>
found this bug using clang-14 with libFuzzer
and drafted an almost correct patch to fix it.
The first half of his patch was correct;
i slightly rearranged it with no functional change
to make the code two lines shorter and easier to read.
[4 lines not shown]
rpki-client: rework cms_parse_validate() further
This diff pulls the signed object handling into cms_parse_validate(),
thereby simplifying the signature quite a bit. signed_object_parse()
remains as a thin wrapper of cms_parse_validate() for now. Perhaps we
will need a signed_object_parse_filemode(), for example.
One benefit of doing this is that the CMS_ContentInfo object lives
during the entire signd object validation, so we no longer need to
create a copy of its eContent OCTET STRING for further processing.
ok claudio
rpki-client: fix handling of inherited resources in leaves
It's been publicly known at least since Frank Denis's "security audit"
dumps back in May that the RFC 3779 inheritance handling in libcrypto's
path validation is broken. Namely, if the certificate to be validated
inherits resources, X509v3_asid_validate_path(3) and friends can succeed
even if one of the certs on the path does not have the corresponding
resource delegation extension at all. RFC 3779's sections 2.3 and 3.3
clearly require that every cert on the entire validating path have the
relevant INR delegation extensions. Frank Denis flagged this for ASIDs,
but it is obvious that IP addresses have the same problem.
For rpki-client, one of the very few (if not the only) consumers of this
code in libcrypto, this doesn't matter all that much because it duplicates
much of the work on INR validation. Per the specification, EE certs with
inherit elements are only in MFTs, TAKs (of which there are none) and
the no longer supported GBRs (of which there is one - malformed). Correct
nesting and presence of RFC 3779 extensions is ensured by rpki-client
except for the leaf.
[33 lines not shown]
Johann Hoepfner found 5 places where un-terminated strings in pf ioctl's
were handled incorrectly but his solution of silently truncating them and
potentially acting on the wrong object decided from the string didn't
satisfy me. I started over, and identified all un-terminated strings
using strlnen and made them return ENAMETOOLONG. There were roughly 40
occurances of this type of bug.
ok sashan
Move code around to result in the same list of case statements in
_bpf_filter and bpf_validate.
Also encode BPF_LDX|BPF_MSH|BPF_B as BPF_LDX|BPF_B|BPF_MSH, all other
BPF_LD / BPD_LDX instructions have BPF_{W,H,B} in 2nd position.
OK tb@
