Remote DoS via receive-side kernel TLS
FreeBSD-SA-26:67.ktls · CVE-2026-101302
Our decision for FreeSense
FreeBSD corrected this on 2026-09-28, after the FreeBSD source pin of FreeSense 1.0 (pinned 2026-08-03). The fix arrives with the next FreeBSD pin of each line that is still updated. No one has checked yet whether FreeSense is exposed in practice.
- Advisory: corrected 2026-09-28
- FreeSense 1.0 pin: e004ff15f87e (2026-08-03)
- FreeSense 1.1 pin: a52c50b4b7c2 (2026-10-04)
- FreeSense 1.2 pin: a52c50b4b7c2 (2026-10-04)
By FreeSense version
| Version | Status | FreeBSD pin |
|---|---|---|
| FreeSense 1.01.0.7 · frozen, no further fixes | Open | 2026-08-03e004ff15 |
| FreeSense 1.11.1.9 | FixedFreeBSD pin of 2026-10-04 | 2026-10-04a52c50b4 |
| FreeSense 1.21.2.0-DEVELOPMENT | FixedFreeBSD pin of 2026-10-04 | 2026-10-04a52c50b4 |
Workaround
Only users running an application which enables receive-side KTLS are affected. Systems with the kern.ipc.tls.enable sysctl set to 0 are unaffected.
What FreeBSD says
TLS 1.3 embeds the actual record type as the last non-zero byte of the decrypted payload, optionally followed by zero padding. The code which searches for the inner record type had an off-by-one bug which could be triggered by an invalid frame, leading to an underflow followed by an unconditional NULL pointer dereference, causing a kernel panic.
Impact
A remote TLS 1.3 peer can send a specially crafted record to trigger a kernel panic, resulting in a Denial of Service (DoS).
Excerpt from the FreeBSD advisory. Read the original for the full text and the fix.