Closed PaulosV closed 10 months ago
Attention: 1 lines
in your changes are missing coverage. Please review.
Comparison is base (
84b4f7d
) 40.90% compared to head (e0dbd6f
) 40.91%.
Files | Patch % | Lines |
---|---|---|
process/wg.cpp | 0.00% | 0 Missing and 1 partial :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
This corrects an implementation flub where I assumed that the length of a WireGuard data packet would always be divisible by 16. That is verifiably false, and the receiving code of WireGuard does not assume that.
Zero-padding the message data to the multiples of 16 relates to memory alignment and is mainly a measure to "complicate traffic analysis". It does not always happen; the most common example is traffic approaching the inner MTU, which is set by default to 1420, but can be set to arbitrary values by the user.
1420 is not divisible by 16, and an IP packet of length 1420 is not padded any further by WireGuard. With additional 32 bytes of WireGuard headers and 32 bytes of UDP, IP and frame headers, the total frame length is 1494, which is, again, not divisible by 16.
So this check needs to go. It may increase the number of false positives, I am going to do some tests about this.