Re: [PATCH net 2/2] wireguard: noise: recheck replay and flood under write lock on initiation

[netdev-bot+sashiko@kernel.org]

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] The commit message names the response-side fix as `commit
  2a73c9b2c0ca ("wireguard: noise: reject response consumption after…

--

wireguard: noise: recheck replay and flood under write lock on initiation

This commit makes wg_noise_handshake_consume_initiation() run the replay
and flood checks a second time after taking handshake->lock for writing.
Without the second check, two copies of the same initiation processed in
parallel could both get past the read-locked check. The read-locked check
stays as a fast path for rejecting replays.

> This is the initiation-side counterpart of the response-side race fixed
> by:
> commit 2a73c9b2c0ca ("wireguard: noise: reject response consumption after intermediate initiation")

[Severity: Low]
Is this the right hash for the referenced commit? 2a73c9b2c0ca doesn't
resolve here. git log reports it as an unknown revision.

The commit with this subject appears to be:

commit d0305f8d9002 ("wireguard: noise: reject response consumption after intermediate initiation")

Running git blame on the response-side recheck under down_write() in
wg_noise_handshake_consume_response() also points to d0305f8d9002:

    if (handshake->state != state ||
        crypto_memneq(handshake->ephemeral_private, ephemeral_private, NOISE_PUBLIC_KEY_LEN)) {

Could the reference be changed to d0305f8d9002? This patch is tagged for
stable, so readers who follow the cited hash to the related fix would
find the right commit.

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261105141006.95083-1-alex%40badcode.im