Re: [PATCH net v2 0/3] amt: fix relay tunnel keying and unauthenticated-Request DoS

[Taehee Yoo]

On Sat, Oct 10, 2026 at 6:37 AM Omar Ramadan <omar@xxxxxxxxxxxxx> wrote:
>

Hi Omar,

Thank you so much for your work!
I'm currently traveling for LPC, so my review will be delayed.
Sorry for the delay. I will take a look at your patches in the next 2-3 days.

Thanks a lot!
Taehee Yoo

> Thanks -- both are fair asks. Answers below; they are also reflected in
> the v2 cover letter. v1 was generated against v7.1 and did not apply to
> net, so this is answered against v2, which is posted against net with the
> General Query patch dropped (that fix is already in net as afae89de73dd).
> v2 is three patches.
>
> How it was found
>   Manual code inspection of the AMT relay path in drivers/net/amt.c, read
>   against RFC 7450, with LLM assistance -- hence the Assisted-by: LLM
>   trailer on patch 3/3. It was not a syzbot report or a static-analysis
>   tool scan. Patch 1/3 (endpoint keying) came out of the same reading of
>   amt_request_handler() and amt_update_handler() against RFC 7450 s4.2.2.
>
> Whether it was triggered
>   Found by inspection; not observed in production. These are availability
>   and correctness defects, not memory-safety bugs, so there is no oops or
>   stack trace to attach. The symptoms follow deterministically from the
>   code the diffs change:
>
>    - 3/3, exhaustion: amt_request_handler() allocated a tunnel before any
>      validation of the source, so Relay Membership Requests from distinct
>      spoofable source endpoints fill the table to max_tunnels (default
>      128). Once full, further Requests are answered with ICMP_DEST_UNREACH
>      to the (spoofed) source and genuine gateways are refused; re-sending
>      once per amt_gmi() interval holds it full.
>    - 3/3, desync: the pre-validation lookup jumped to the send path and
>      overwrote an established tunnel's ->nonce/->mac, so a single spoofed
>      Request carrying a known gateway's source endpoint made that
>      gateway's next Membership Update fail the "Invalid MAC" check -- a
>      silent one-packet denial that consumes no table slot.
>    - 1/3, aliasing: address-only keying collapses two endpoints that share
>      a source address (NAT, or one host using separate IPv4/IPv6 ports per
>      RFC 7450 s4.2.2) onto one tunnel; the later Request wins and the
>      earlier gateway silently stops receiving.
>
>   I have not staged a live end-to-end exploit run -- the above is read
>   from the code paths, not a captured trace.
>
> Fix testing (this part is observed, not inferred)
>   The three patches were applied to net and the kernel booted (arm64,
>   QEMU via virtme-ng) with CONFIG_KASAN=y, CONFIG_PROVE_LOCKING=y,
>   CONFIG_PROVE_RCU=y and CONFIG_DEBUG_LIST=y on top of
>   tools/testing/selftests/net/config. tools/testing/selftests/net/amt.sh
>   passes all six tests -- amt discovery, IPv4 and IPv6 multicast
>   forwarding, and both IPv4/IPv6 traffic-forwarding torture cases all
>   report [ OK ] -- with no KASAN, lockdep or RCU reports.