Location
src/safety/mod.rs — the E2E header layout, the sequence-gap check, and the CRC-16 implementation; safety-case.md (sub-claim SC-10).
Problem
Two separate issues in the same module:
-
Mislabeled as standards-grade E2E. The safety module ships a custom 10-byte header (DataID, SourceID, sequence counter, CRC-16/CCITT-FALSE) that the module doc comment and the safety case both describe as ISO 26262 ASIL-B end-to-end data protection. It doesn't correspond to any of the standard AUTOSAR E2E profiles — the byte layout, CRC width/offsets, counter width, and how the Data ID is handled all differ from every named profile. The safety case cites it as qualifying E2E evidence, but as implemented it's a bespoke integrity scheme, not an instance of a recognized profile.
-
Sequence-gap detection silently re-syncs after the first gap. In the receiver's unwrap path, when a sequence-counter gap is detected, the code advances its internal last_seq to the received (out-of-order) value before returning the SequenceGap error. That means only the first gap in a burst of missing/reordered/replayed frames is ever reported — any subsequent out-of-order frame in the same burst is silently accepted as the new baseline, which weakens exactly the replay/loss detection this module is meant to provide.
Suggested fix
Either implement and cite a named AUTOSAR E2E profile, or explicitly document this scheme in the safety case as a non-standard integrity check rather than qualifying E2E evidence. Separately, don't advance last_seq on a detected gap (or, if resyncing on the first-error is an intentional design choice, document that behavior explicitly as a requirement and add a test that exercises multiple consecutive gaps to show the actual detection behavior).
Filed from the 2026-07-29 ecosystem audit register; independently re-verified against current HEAD before filing.
Location
src/safety/mod.rs— the E2E header layout, the sequence-gap check, and the CRC-16 implementation;safety-case.md(sub-claim SC-10).Problem
Two separate issues in the same module:
Mislabeled as standards-grade E2E. The
safetymodule ships a custom 10-byte header (DataID, SourceID, sequence counter, CRC-16/CCITT-FALSE) that the module doc comment and the safety case both describe as ISO 26262 ASIL-B end-to-end data protection. It doesn't correspond to any of the standard AUTOSAR E2E profiles — the byte layout, CRC width/offsets, counter width, and how the Data ID is handled all differ from every named profile. The safety case cites it as qualifying E2E evidence, but as implemented it's a bespoke integrity scheme, not an instance of a recognized profile.Sequence-gap detection silently re-syncs after the first gap. In the receiver's unwrap path, when a sequence-counter gap is detected, the code advances its internal
last_seqto the received (out-of-order) value before returning theSequenceGaperror. That means only the first gap in a burst of missing/reordered/replayed frames is ever reported — any subsequent out-of-order frame in the same burst is silently accepted as the new baseline, which weakens exactly the replay/loss detection this module is meant to provide.Suggested fix
Either implement and cite a named AUTOSAR E2E profile, or explicitly document this scheme in the safety case as a non-standard integrity check rather than qualifying E2E evidence. Separately, don't advance
last_seqon a detected gap (or, if resyncing on the first-error is an intentional design choice, document that behavior explicitly as a requirement and add a test that exercises multiple consecutive gaps to show the actual detection behavior).Filed from the 2026-07-29 ecosystem audit register; independently re-verified against current HEAD before filing.