Repository navigation
fix(corekit): a capture cut inside an option area is refused, and loudly, instead of a short read #2694
Description
Found while re-reviewing #2683; identical on main. Under the #1325 guards, OptionField.unpack refuses a capture cut that lands before or inside an option area: "runs past the end of the data" via _ShortReadTracker, and "consumed no data" from the zero-progress check. This hits 13 option-bearing MH message types, and HOPOPT cut to 2 or 3 octets.
- Inside IPv6 the cut layer is kept as
Rawand rebuilds byte for byte. - The "consumed no data" cases are not quiet. They log a CRITICAL
FieldValueErrorand a beholder WARNING, against the handled-refusals-are-quiet rule. - Standalone,
MH(cut)raises where a capture cut belongs toSchema's built-in short read.
Decide whether a cut inside an option area should parse via the built-in, as #2682 does for SCTP's padding. Either way, the refusal kept as Raw must log nothing.
Activity
JarryShaw commentedon Nov 2, 2026
Blocked on #2682, which reworks
OptionField's #1325 guard for SCTP. This issue starts once that lands, so the two cannot conflict.blocked.JarryShaw commentedon Nov 2, 2026
Another case of the same kind, from #2700's review and identical on
main: MH option 44 with an odd length raisesFieldValueErrorfrom corekit's list field. Inside IPv6 that logs five CRITICAL records, although the layer is kept asRaw. Option 48 logs seven records.JarryShaw commentedon Nov 3, 2026
Another case of the same kind, found on #2691 and present on
main: a capture cut inside the reserved octets of an MH LRI or UPA message raises a bareFieldValueErrorfrom the options field while parsing.JarryShaw commentedon Nov 3, 2026
#2682 has merged as
bd82b7632, and it already reads a cut option area as a short read for SCTP padding. A worker is extending the sameSchemashort-read mechanism to every case here, so that nothing is logged.wip.JarryShaw commentedon Nov 3, 2026
The worker has the MH part: a cut inside or before an MH option area, or inside the LRI/UPA reserved octets, now parses as a recorded short read through
Schema's built-in, rebuilds byte-exactly and logs no refusal.Needs deciding: a standalone cut HOPOPT or IPv6-Opts. The schema now records the cut, but the layer still refuses it in its "options must fill the area" check. Inside IPv6 it stays a quiet, exact
Raw; on its own,HOPOPT(cut)raises.HOPOPT.makeandIPv6_Opts.makethen rebuild the declared Hdr Ext Len, as MH's maker does. This overturns A malformed known IPv6 extension header should parse as Raw, not IPv6_Ext #2477'stest_cut_header_is_raw_and_ends_the_walk.Raw.Recommendation: 1. Your ruling puts capture cuts in
Schema's built-in short read, and whatever parses also builds. I'm going ahead with 1 in this commit unless you pick 2. The odd-length MH options 44 and 48 from the second comment are going into the same commit.JarryShaw commentedon Nov 3, 2026
take 1
JarryShaw commentedon Nov 3, 2026
Ruling taken: option 1. A standalone cut HOPOPT or IPv6-Opts header parses as a recorded short read. Their
make()gains what it needs to rebuild the declared Hdr Ext Len, and #2477'stest_cut_header_is_raw_and_ends_the_walkmoves to the new behaviour, citing this issue.How this fits with the rest: the worker was already on option 1, so nothing changes in flight. The odd-length MH options 44 and 48 and the conventions paragraph for the short-read ruling go in the same commit.
needs: decisionis removed and the issue stayswip.JarryShaw commentedon Nov 3, 2026
The PR is #2731.
fix(internet)!: read a cut after an IPv6 option's type octet as a sho…