Repository navigation
fix(sctp): an INIT or ABORT whose final parameter or cause omits its padding is rejected at parse #1479
Description
An SCTP INIT or ABORT whose final parameter or error cause is sent without its trailing padding, at the end of the packet, is rejected when parsed. RFC 9260 §3.2 allows the last padding to be omitted. This happens on main (6323852a7) and on #1477.
Repro:
| Case | Input (hex) | Result |
|---|---|---|
| INIT, final Host Name (type 11) unpadded | 13881389deadbeef000000000100001d00000001000003e8000a000a00000001000b00096162636465 |
ProtocolError: Field parameters has an option that runs past the end of the data: <Parameter.Host_Name_Address: 11> at offset 0 of 12, with only 9 octet(s) of it present |
| ABORT, final User_Initiated_Abort (code 12) unpadded | 13881389deadbeef000000000600000b000c0007616263 |
ProtocolError: Field error has an option that runs past the end of the data: <CauseCode.User_Initiated_Abort: 12> at offset 0 of 8, with only 7 octet(s) of it present |
The same failure occurs with a final parameter of type 0x8000, with a sole unpadded parameter, and with two causes where the last one is unpadded. ERROR, INIT ACK and ASCONF are likely affected too (unverified).
Cause: the nested parameter/cause list parser requires each item's padded size.
Expected: parse the packet and rebuild it byte-exactly through from_data(info) and from_data(info.to_dict()), as #1477 does for the final chunk.
Found by the #1477 cross-review. Blocked until #1477 merges: #1477 owns pcapkit/protocols/schema/transport/sctp.py and pcapkit/protocols/transport/sctp.py, where this fix goes.
Activity
JarryShaw commentedon Oct 9, 2026
Unblocked: #1477 merged (
ed3064c75), sopcapkit/protocols/schema/transport/sctp.pyandpcapkit/protocols/transport/sctp.pyare free. A worker is starting on this against currentmain.fix(sctp): accept a final parameter or cause short of its padding (#1479