mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Paul Fertser <fercerpav@gmail.com>
To: Jerry C Chen <Jerry_C_Chen@wiwynn.com>
Cc: patrick@stwcx.xyz, Samuel Mendoza-Jonas <sam@mendozajonas.com>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Simon Horman <horms@kernel.org>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1] net/ncsi: fix buffer overflow in getting version id
Date: Thu, 27 Feb 2025 11:55:45 +0300	[thread overview]
Message-ID: <Z8AokYA+ZNsxnHaG@home.paul.comp> (raw)
In-Reply-To: <20250227055044.3878374-1-Jerry_C_Chen@wiwynn.com>

Hello Jerry,

Thank you for the patch.

You should be able to follow progress on the Patchwork[0]. What
upstream tree did you intend it for and why? It doesn't apply cleanly
to net-next, that's for sure.

More inline.

On Thu, Feb 27, 2025 at 01:50:44PM +0800, Jerry C Chen wrote:
> In NC-SI spec v1.2 section 8.4.44.2, the firmware name doesn't
> need to be null terminated while its size occupies the full size
> of the field.

Right, the specification guarantees null-termination if there's enough
space for it but also allows the firmware name to occupy all the 12
bytes and then it's not null-terminated.

Have you seen such cards in the wild? It wouldn't harm mentioning
specific examples in the commit message to probably help people
searching for problems specific to them later. You can also consider
adding Fixes: and Cc: stable tags if this bugfix solves a real issue
and should be backported to stable kernels.

> Fix the buffer overflow issue by adding one
> additional byte for null terminator.

This buffer is only written to by

ncsi-rsp.c:     memcpy(ncv->fw_name, rsp->fw_name, 12);

hence there's no possibility of overflow. The real problem is the
potential lack of the terminating NULL when it's later used by

nla_put_string(skb, NCSI_CHANNEL_ATTR_VERSION_STR, nc->version.fw_name);

which indeed expects a "NUL terminated string". But how exactly does
your patch guarantee that the 13th byte of fw_name is going to be NUL
is unclear. I suggest it's done explicitly in the code after memcpy.

> WIWYNN PROPRIETARY
> This email (and any attachments) contains proprietary or confidential information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or distribution of this email or the content of this email is strictly prohibited. If you are not the intended recipient, please notify the sender and delete this email immediately.

There should be nothing "proprietary or confidential" about your
patches for upstream. It's not unlikely the maintainers will be
ignoring patches from you containing this notice because they have no
way to determine who is the intended recipient and what exactly is
authorised.

[0] https://patchwork.kernel.org/project/netdevbpf/patch/20250227055044.3878374-1-Jerry_C_Chen@wiwynn.com/

  reply	other threads:[~2025-02-27  8:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-27  5:50 Jerry C Chen
2025-02-27  8:55 ` Paul Fertser [this message]
2025-05-15  8:34 Jerry C Chen
2025-05-15  9:04 ` Paul Fertser
2025-05-23  7:32   ` Jerry C Chen/WYHQ/Wiwynn
2025-05-26 20:15     ` Paul Fertser
2025-05-27  2:23       ` Jerry C Chen/WYHQ/Wiwynn

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=Z8AokYA+ZNsxnHaG@home.paul.comp \
    --to=fercerpav@gmail.com \
    --cc=Jerry_C_Chen@wiwynn.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=patrick@stwcx.xyz \
    --cc=sam@mendozajonas.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

all inboxes | Powered by JetHome®