netdev - Re: [PATCH net] net: dsa: validate source trunk against lags

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <42BC8652-49EC-4BB6-8077-DC77BCA2A884@padl.com>
Date: Thu, 31 Jul 2025 19:55:06 +1000
From: Luke Howard <lukeh@...l.com>
To: Vladimir Oltean <olteanv@...il.com>
Cc: netdev@...r.kernel.org, Andrew Lunn <andrew@...n.ch>,
        Ryan Wilkins <Ryan.Wilkins@...osalliance.com>
Subject: Re: [PATCH net] net: dsa: validate source trunk against lags_len

Hi Vladimir,

Thanks for helping me walk through my first kernel patch (I thought I would start with a one line one!).

> 1. You need to add a Fixes: tag, like the following:
> Fixes: 5b60dadb71db ("net: dsa: tag_dsa: Support reception of packets from LAG devices")

Noted.

> 2. The problem statement must not remain in the theoretical realm if you
>   submit a patch intended as a bug fix. Normally the tagger is used to
>   process data coming from the switch hardware, so to trigger an
>   out-of-bounds array access would imply that the problem is elsewhere.
>   That, or you can make it clear that the patch is to prevent a
>   modified dsa_loop from crashing when receiving crafted packets over a
>   regular network interface. But using dsa_loop with a modified
>   dsa_loop_get_protocol() return value is a developer tool which
>   involves modifying kernel sources. I would say any fix that doesn't
>   fix any real life problem in production systems should be sent to
>   'net-next', not to 'net'. This is in accordance with
>   Documentation/process/stable-kernel-rules.rst.

Thanks for the clarification, I was unsure which to send to: I’ll send the revised patch to net-next instead.

Ryan (on cc) saw this crash with a Marvell switch, using some not yet submitted patches to support in-band switch management without MDIO.

Exactly what caused the switch to deliver a malformed DSA packet is unknown, but it seems reasonable to expect the kernel to be resilient to this (although one could make an argument that the trust boundary extends to the switch chip).

> 3. As per Documentation/process/submitting-patches.rst, you should
>   replace the wording "This patch adds" with the imperative mood.

Noted.

> 4. Please use ./scripts/get_maintainer.pl to generate the recipient
>   list, don't send patches just to the mailing list, reviewers might
>   miss them.

Noted, I just added Andrew for now.

Cheers,
Luke