All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Daniel Golle <daniel@makrotopia.org>
Cc: Andrew Lunn <andrew@lunn.ch>, Vladimir Oltean <olteanv@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next] net: dsa: mxl862xx: don't read out-of-bounds
Date: Thu, 19 Mar 2026 16:44:12 +0000	[thread overview]
Message-ID: <20260319164412.GL1753385@horms.kernel.org> (raw)
In-Reply-To: <83356ad9c9a4470dd49b6b3d661c2a8dd85cc6a1.1773803190.git.daniel@makrotopia.org>

On Wed, Mar 18, 2026 at 03:07:52AM +0000, Daniel Golle wrote:
> The write loop in mxl862xx_api_wrap() computes the word count as
> (size + 1) / 2, rounding up for odd-sized structs.
> 
> On the last iteration of an odd-sized buffer it reads a full __le16
> from data[i], accessing one byte past the end of the caller's struct.
> KASAN catches this as a stack-out-of-bounds read during probe (e.g.
> from mxl862xx_bridge_config_fwd() because of the odd length of
> sizeof(struct mxl862xx_bridge_config) == 49).
> 
> The read-back loop already handles this case, it writes only a single
> byte when (i * 2 + 1) == size. The write loop lacked the same guard.
> 
> In practice the over-read is harmless: the extra stack byte is sent to
> the firmware which ignores trailing data beyond the command's declared
> payload size.
> 
> Apply the same odd-size last-byte handling to the write path: when the
> final word contains only one valid byte, send *(u8 *)&data[i] instead
> of le16_to_cpu(data[i]). This is endian-safe because data is
> __le16-encoded and the low byte is always at the lowest address
> regardless of host byte order.
> 
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>

Reviewed-by: Simon Horman <horms@kernel.org>


  reply	other threads:[~2026-03-19 16:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-18  3:07 [PATCH net-next] net: dsa: mxl862xx: don't read out-of-bounds Daniel Golle
2026-03-19 16:44 ` Simon Horman [this message]
2026-03-21  1:40 ` patchwork-bot+netdevbpf

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=20260319164412.GL1753385@horms.kernel.org \
    --to=horms@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=daniel@makrotopia.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.