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: <20250731090753.tr3d37mg4wsumdli@skbuf>
Date: Thu, 31 Jul 2025 12:07:53 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: Luke Howard <lukeh@...l.com>
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH net] net: dsa: validate source trunk against lags_len

Hello Luke,

On Thu, Jul 31, 2025 at 03:35:34PM +1000, Luke Howard wrote:
> A DSA frame with an invalid source trunk ID could cause an out-of-bounds read
> access of dst->lags.
> 
> This patch adds a check to dsa_lag_by_id() to validate the LAG ID is not zero,
> and is less than or equal to dst->lags_len. (The LAG ID is derived by adding
> one to the source trunk ID.)
> 
> Note: this is in the fast path for any frames within a trunk.
> 
> Signed-off-by: Luke Howard <lukeh@...l.com>
> ---
>  include/net/dsa.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/include/net/dsa.h b/include/net/dsa.h
> index 2e148823c366c..67672c5ff22e5 100644
> --- a/include/net/dsa.h
> +++ b/include/net/dsa.h
> @@ -180,6 +180,9 @@ struct dsa_switch_tree {
>  static inline struct dsa_lag *dsa_lag_by_id(struct dsa_switch_tree *dst,
>  					    unsigned int id)
>  {
> +	if (unlikely(id == 0 || id > dst->lags_len))
> +		return NULL;
> +
>  	/* DSA LAG IDs are one-based, dst->lags is zero-based */
>  	return dst->lags[id - 1];
>  }
> -- 
> 2.43.0

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

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.

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

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.