You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(ipv6): a truncated IPv6 extension header rebuilds padded to its declared length #1451
Bug. An IPv6 extension header cut short inside itself does not rebuild byte-exact from its own info. The rebuild pads the header out to its declared length.
Repro on main (78991b7d5): a Routing header declares 24 octets (Hdr Ext Len 2), but only 23 are captured.
The #1449 cross-review reports the same for AH. It also cut every extension header class at 8 points and found other truncated cases fail the same way.
Found during the #1449 review. #1449 itself does not change this behaviour, because its trim only shortens.
Blocked until #1449 merges.#1449 changes how extension-mode headers trim their data, in internet.py, and this fix lives in the same files. A worker will start from main once #1449 is in.
Related: #1458 is the general form of this bug. Any header cut inside a fixed-width field is zero-filled on parse (pcapkit/corekit/fields/field.py:586), across every protocol family. The worker on this issue is checking whether the corekit root cause is what drives the IPv6 extension-header case, so the two may close together.
A fix is ready on fix/1451-truncated-ext-header (96488354b). It rejects a truncated extension header and keeps the octets as captured. Before I open the PR, I've asked on #1458 whether to take that approach or fix the zero-fill in corekit instead; the corekit fix would cover this issue too.
Activity
JarryShaw commentedon Oct 9, 2026
Blocked until #1449 merges. #1449 changes how extension-mode headers trim their data, in
internet.py, and this fix lives in the same files. A worker will start frommainonce #1449 is in.JarryShaw commentedon Oct 9, 2026
Unblocked: #1449 merged as
2f7aadd08. Back topending; a worker can now start frommain.JarryShaw commentedon Oct 9, 2026
A worker is on it now, on branch
fix/1451-truncated-ext-header.JarryShaw commentedon Oct 9, 2026
Related: #1458 is the general form of this bug. Any header cut inside a fixed-width field is zero-filled on parse (
pcapkit/corekit/fields/field.py:586), across every protocol family. The worker on this issue is checking whether the corekit root cause is what drives the IPv6 extension-header case, so the two may close together.JarryShaw commentedon Oct 9, 2026
A fix is ready on
fix/1451-truncated-ext-header(96488354b). It rejects a truncated extension header and keeps the octets as captured. Before I open the PR, I've asked on #1458 whether to take that approach or fix the zero-fill in corekit instead; the corekit fix would cover this issue too.JarryShaw commentedon Oct 9, 2026
Decided on #1458: the fix goes into corekit (option 2), and that PR will close this issue too. The reject-based branch is dropped.
test(protocols): edge-case round trips for every layer family (#1202)
test(protocols): edge-case round trips for every layer family (#1202)
test(protocols): edge-case round trips for every layer family (#1202) (…
test(roundtrip): drop the edge-case gaps that #1460, #1462 and #1463 …
fix(schema): a header cut inside a fixed-width field rebuilds as capt…
fix(schema): a header cut inside a fixed-width field rebuilds as capt…
fix(schema): a header cut inside a fixed-width field rebuilds as capt…