From: Sabrina Dubroca <sd@queasysnail.net>
To: Sung Byeongchan <tjdqudcks0424@naver.com>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH net] macsec: ignore inactive receive secure channels
Date: Thu, 8 Oct 2026 15:26:38 +0200 [thread overview]
Message-ID: <aseaDtd5ys5Fom7e@krikkit> (raw)
In-Reply-To: <20261008082612.350120-1-tjdqudcks0424@naver.com>
Hello,
This probably doesn't need to be called a bugfix that goes to net
(2554c08e16aa ("macsec: check the resolved SCI for duplicates") went
to net-next).
2026-10-08, 17:26:12 +0900, Sung Byeongchan wrote:
> The receive path looks up an RXSC by SCI without checking its active flag.
> An active child RXSA can therefore authenticate and deliver frames after
> userspace has administratively disabled the RXSC.
>
> Restrict the receive-only RCU lookup to active RXSCs. Keep the RTNL lookup
> used for configuration unchanged so userspace can reactivate or remove an
> inactive channel.
Function names please. I don't know why LLMs are so opposed to precise
references to the code.
This is a change of user-visible behavior. I don't think it matters
because this flag is probably unused (at least, it's unused by both
wpa_supplicant and MKAdaemon), but it's a change nonetheless and
deserves a mention in the commit message.
(it's one of those things that I implemented because it's in the spec,
but that I should have skipped in retrospect)
> All three baseline runs delivered a valid protected frame while an
> independent state dump reported the RXSC off. All three fixed runs rejected
> the frame. RXSC reactivation and RXSA off/on controls retained their
> expected behavior.
Out of curiosity: why 3 runs, what's different between them?
This would be worth a small selftest, since we don't have a lot of
traffic tests currently. Just something that does:
set up everything with active RXSCs
send a few packets, make sure they arrive
disable the RXSC
send a few packets, make sure they get dropped
re-enable the RXSC
send a few packets, make sure they arrive
(this would be a separate patch, see for example
https://lore.kernel.org/all/20261001-fix-macsec-duplicate-sci-v3-2-0f179fbe1f2d@gmail.com/)
--
Sabrina
prev parent reply other threads:[~2026-10-08 13:26 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-08 8:26 [PATCH net] macsec: ignore inactive receive secure channels Sung Byeongchan
2026-10-08 13:26 ` Sabrina Dubroca [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aseaDtd5ys5Fom7e@krikkit \
--to=sd@queasysnail.net \
--cc=netdev@vger.kernel.org \
--cc=tjdqudcks0424@naver.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox