Repository navigation
DTLS reassembly has no buffer-size cap (unlike IP reassembly's 64KiB limit) #2468
Description
Describe the bug
DTLS handshake reassembly (pcapkit.foundation.reassembly.dtls.DTLS, added in #2440/#2451)
allocates a message's whole bytearray(length) up front, from the message's own declared
length field, with no upper bound. IP reassembly caps this at 64KiB
(pcapkit.foundation.reassembly.ip); DTLS reassembly has no equivalent cap.
Reproduction
A single DTLS handshake fragment declaring a length near the 24-bit field's max
(16,777,215) is enough on its own to make the reassembler allocate ~16MiB for one
message — one buffer per (BufferID, message_seq), not several. Reaching larger
totals (e.g. ~320MiB) needs multiple distinct message_seq values, each holding
its own such buffer open at once; a single shared message_seq with alternating
fragment lengths can also grow past 16MiB when strict=False, since each displaced
partial keeps its full-length bytes.
Expected behavior
Like pcapkit.foundation.reassembly.ip's 64KiB cap, a declared length past some
ceiling should be rejected or clipped rather than allocated verbatim.
System information
Not version-specific — pcapkit/foundation/reassembly/dtls.py,
frag = Fragment(..., raw=bytearray(length), ...), present since #2440 (round 1),
unchanged through #2451's later rounds.
Additional context
Found during #2451's cross-review (round 3), as a non-blocking follow-up: it predates
round 3 and is not something that round fixed or regressed, so it is filed separately.
Existing tests do not catch it because none construct a message with an outsized
declared length and no corresponding payload.
Activity
JarryShaw commentedon Oct 30, 2026
Blocked by open issue/pr or waiting for resources? SWEEP not checking in on this one?
JarryShaw commentedon Oct 30, 2026
Not blocked — I just deprioritized it under host load and never circled back. Dispatching now.
JarryShaw commentedon Oct 30, 2026
Then note to memory and SWEEP that pending ones should always be checked. If pending load resources, comment as well. And pick up when load is fine.
I'd consider besides host load, GHA's CI load is another thing we should take into consideration when dispatching worker subagents. Avoid too long wait time for each round and the main branch builds. Note this to the memory as well.
JarryShaw commentedon Oct 30, 2026
Noted — both saved to memory and sweep.md: pending issues checked every tick with an on-issue comment when held for load, and Actions queue depth now weighed alongside host load before a wide dispatch.
fix(foundation/reassembly): cap DTLS handshake message allocation at …
JarryShaw commentedon Oct 31, 2026
Decision needed, same as #2469: close, or re-scope to declared-length sizing tests. Recommendation: close, since the 64KiB cap is dropped and origin already pins buffers at the declared length.
JarryShaw commentedon Oct 31, 2026
close. buffer cap no longer needed under HDL algo impl.
JarryShaw commentedon Oct 31, 2026
Closing per owner ruling: buffer cap no longer needed under the HDL implementation.