sys/video: fix video buffer handling and mmap lifetime
Check dequeue errors and allocation bounds, correct the mmap buffer base,
and revoke user mappings before freeing capture buffers.
Based on diffs from Acts1631, thanks!
OK: mglocker@
Back out the last video(4) vulnerability fix, which changed the
kern.video.record behavior. We found a solution in the meantime to
fix the vulnerability without changing the previous kern.video.record
behavior (blanking), which will be committed next.
ok deraadt@, kirill@
sys/video: fix video buffer handling and mmap lifetime
Check dequeue errors and allocation bounds, correct the mmap buffer base,
and revoke user mappings before freeing capture buffers.
Based on diffs from Acts1631, thanks!
from kirill@; OK mglocker@
this is errata/8.0/004_video.patch.sig
sys/video: fix video buffer handling and mmap lifetime
Check dequeue errors and allocation bounds, correct the mmap buffer base,
and revoke user mappings before freeing capture buffers.
Based on diffs from Acts1631, thanks!
from kirill@; OK mglocker@
this is errata/7.9/039_video.patch.sig
sys/video: fix video buffer handling and mmap lifetime
Check dequeue errors and allocation bounds, correct the mmap buffer base,
and revoke user mappings before freeing capture buffers.
Based on diffs from Acts1631, thanks!
from kirill@; OK mglocker@
this is errata/7.8/075_video.patch.sig
Implement draft-herdes-idr-otc-rs-verification-01
For route-server clients OTC handling should be performed like for the
peer-to-peer role. This is because the route-server itself should tag
all routes with its own AS in the OTC attribute. So if the OTC attribute
is set but not equal to the RS AS then this is a leak.
OK tb@ job@
Join a skin tone only to the emoji before it, it was originally
incorrectly joined to the one after, and when that was fixed the check
was added rather than replaced. From someone in GitHub issue 5764.
rpki-client: fix doc comment on maxLength in extern.h
Since roa.c 1.6 (2019), the maxlength member of struct roa_ip is set to
the prefix length rather than zero if the maxLength element is absent.
While this move simplified some things, it also required some complexity.
Maybe this needs revisiting at some point.
For now stop lying (something these dumb comments often end up doing...)
rpki-client: expose superfluous ROAIPAddress maxLength
Per RFC 9582, section 4.3.2.2, the optional maxLength element of a
ROAIPAddress indicates the maximum length of an IP address prefix that
the ROA authorizes the AS to advertise. If it matches the prefix length,
this carries no additional information, so it can and SHOULD be omitted.
In the good old tradition of sacrificing far too many lambs on the altar
of Postel, this SHOULD could not be made a MUST.
As of today, 26606 out of 398347 ROAs (6.7%) carry this extra element.
Our internal struct roa_ip has a maxlength containing the value of the
maxLength (if present) or the prefix length. This lossy representation
discards the info whether the maxlength should have been there.
This commit adds that info. I made the slightly dubious choice of using
a 1-byte boolean because then it lands in a padding byte, thus avoiding
a few megs of memory overhead in normal mode.
[9 lines not shown]
Fix overflow in hardware accelerated AES-GMAC crypto.
On amd64 using AES-NI or on octeon with crypto coprocessor, an
unauthenticated ESP packet that matches a configured AES-GMAC
security association could copy almost 64 KB of attacker-controlled
data into a 4096-byte kernel heap buffer.
from Acts1631; from bluhm@; OK visa@ hshoexer@
this is errata/8.0/003_aesgmac.patch.sig
Fix overflow in hardware accelerated AES-GMAC crypto.
On amd64 using AES-NI or on octeon with crypto coprocessor, an
unauthenticated ESP packet that matches a configured AES-GMAC
security association could copy almost 64 KB of attacker-controlled
data into a 4096-byte kernel heap buffer.
from Acts1631; from bluhm@; OK visa@ hshoexer@
this is errata/7.9/038_aesgmac.patch.sig
Fix overflow in hardware accelerated AES-GMAC crypto.
On amd64 using AES-NI or on octeon with crypto coprocessor, an
unauthenticated ESP packet that matches a configured AES-GMAC
security association could copy almost 64 KB of attacker-controlled
data into a 4096-byte kernel heap buffer.
from Acts1631; from bluhm@; OK visa@ hshoexer@
this is errata/7.8/074_aesgmac.patch.sig
Backport security fixes from upstream nsd(8) version 4.15.3.
* CVE-2026-101341: Stack overwrite from specially formatted TXT-DATA
RDATA field
* CVE-2026-101339: Stack overwrite from a specially crafted and
formatted HIP RR
* CVE-2026-101338: Stack overwrite from a specially crafted and
formatted SVCB or HTTPS RR
* CVE-2026-101337: Stack overwrite from specially formatted base64
RDATA field
from bluhm@; OK sthen@ renaud@ deraadt@
this is errata/8.0/002_nsd.patch.sig
Backport security fixes from upstream nsd(8) version 4.15.3.
* CVE-2026-101341: Stack overwrite from specially formatted TXT-DATA
RDATA field
* CVE-2026-101339: Stack overwrite from a specially crafted and
formatted HIP RR
* CVE-2026-101338: Stack overwrite from a specially crafted and
formatted SVCB or HTTPS RR
* CVE-2026-101337: Stack overwrite from specially formatted base64
RDATA field
from bluhm@; OK sthen@ renaud@ deraadt@
this is errata/7.9/037_nsd.patch.sig
Backport security fixes from upstream nsd(8) version 4.15.3.
* CVE-2026-101341: Stack overwrite from specially formatted TXT-DATA
RDATA field
* CVE-2026-101339: Stack overwrite from a specially crafted and
formatted HIP RR
* CVE-2026-101338: Stack overwrite from a specially crafted and
formatted SVCB or HTTPS RR
* CVE-2026-101337: Stack overwrite from specially formatted base64
RDATA field
from bluhm@; OK sthen@ renaud@ deraadt@
this is errata/7.8/073_nsd.patch.sig
Fix overflow in hardware accelerated AES-GMAC crypto.
On amd64 using AES-NI or on octeon with crypto coprocessor, an
unauthenticated ESP packet that matches a configured AES-GMAC
security association could copy almost 64 KB of attacker-controlled
data into a 4096-byte kernel heap buffer.
from Acts1631; OK visa@ hshoexer@
isakmpd: Bound the HASH coverage in cfg_verify_hash()
The verifier assumed the HASH payload is the first payload and
derived the covered length from the message length, reading past
the end of the message when another payload precedes HASH. Compute
the covered range from the HASH payload's actual position and reject
it if it extends past the message end.
from hshoexer@; from markus@; OK hshoexer@ deraadt@
this is errata/7.9/036_isakmpd.patch.sig
isakmpd: Bound the HASH coverage in cfg_verify_hash()
The verifier assumed the HASH payload is the first payload and
derived the covered length from the message length, reading past
the end of the message when another payload precedes HASH. Compute
the covered range from the HASH payload's actual position and reject
it if it extends past the message end.
from hshoexer@; from markus@; OK hshoexer@ deraadt@
this is errata/7.8/072_isakmpd.patch.sig
Fix an off-by-one in bsd_decompress()
An incorrect bounds check for the LZW KwKwK case allows the creation of a
self-refential dictionary entry, resulting in an infinite expansion loop
that writes backward from the output mbuf, corrupting kernel memory.
This is an ancient buffer overflow that is also present in the version of
the code in RFC 1977.
from Acts1631; from tb@; OK deraadt@
this is errata/8.0/001_ppp.patch.sig
Fix an off-by-one in bsd_decompress()
An incorrect bounds check for the LZW KwKwK case allows the creation of a
self-refential dictionary entry, resulting in an infinite expansion loop
that writes backward from the output mbuf, corrupting kernel memory.
This is an ancient buffer overflow that is also present in the version of
the code in RFC 1977.
from Acts1631; from tb@; OK deraadt@
this is errata/7.9/035_ppp.patch.sig
Fix an off-by-one in bsd_decompress()
An incorrect bounds check for the LZW KwKwK case allows the creation of a
self-refential dictionary entry, resulting in an infinite expansion loop
that writes backward from the output mbuf, corrupting kernel memory.
This is an ancient buffer overflow that is also present in the version of
the code in RFC 1977.
from Acts1631; from tb@; OK deraadt@
this is errata/7.8/071_ppp.patch.sig
