kern/58480: experimental wg(4) sliding window logic has oopsie

[campbell+netbsd%mumble.net@localhost]

>Number:         58480
>Category:       kern
>Synopsis:       experimental wg(4) sliding window logic has oopsie
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jul 28 13:00:00 +0000 2024
>Originator:     Taylor R Campbell
>Release:        current, 10
>Organization:
The NetWG Windation
>Environment:
>Description:
The sliding window logic in wg(4), used to detect replays, uses a large bitmap represented by an array of words.  It has a definition for the number of bits per word:

#define	SLIWIN_BPW	NBBY*sizeof(SLIWIN_TYPE)

When writing this definition, I sloppily neglected to parenthesize it.  So when it is used in expressions like:

		uint64_t i = W->T / SLIWIN_BPW;
		uint64_t j = S / SLIWIN_BPW;

or

	word = (S / SLIWIN_BPW) % SLIWIN_WORDS;
	bit = S % SLIWIN_BPW;

the meaning is rather different from what was intended.

Amazingly, however, it appears that this doesn't lead to any out-of-bounds memory access -- because that is always explicitly done with W->B[... % SLIWIN_WORDS] -- or even undefined behaviour -- because although S % SLIWIN_BPW, i.e., S % 8 * 4, runs through {0, 4, 8, 12, 16, 20, 24, 28} instead of {0, 1, 2, 3, ..., 31} as intended, all of the results are valid shifts.

So we effectively ended up, by accident, with a much smaller sliding window than intended, but no other adverse consequences.  And it still requires reordering packets by the hundreds in order to detect anything wrong.

Obviously this sliding window logic needs some automatic tests of its own!
>How-To-Repeat:
code inspection
>Fix:
make it lispier