From: David Miller <davem@davemloft.net>
To: alobakin@marvell.com
Cc: kuba@kernel.org, irusskikh@marvell.com,
michal.kalderon@marvell.com, aelior@marvell.com,
denis.bolotin@marvell.com, GR-everest-linux-l2@marvell.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net] net: qed: prevent buffer overflow when collecting debug data
Date: Fri, 03 Jul 2020 12:59:33 -0700 (PDT) [thread overview]
Message-ID: <20200703.125933.1255981278532631718.davem@davemloft.net> (raw)
In-Reply-To: <20200703090258.2076-1-alobakin@marvell.com>
From: Alexander Lobakin <alobakin@marvell.com>
Date: Fri, 3 Jul 2020 12:02:58 +0300
> When generating debug dump, driver firstly collects all data in binary
> form, and then performs per-feature formatting to human-readable if it
> is supported.
> The size of the new formatted data is often larger than the raw's. This
> becomes critical when user requests dump via ethtool (-d/-w), as output
> buffer size is strictly determined (by ethtool_ops::get_regs_len() etc),
> as it may lead to out-of-bounds writes and memory corruption.
>
> To not go past initial lengths, add a flag to return original,
> non-formatted debug data, and set it in such cases. Also set data type
> in regdump headers, so userland parsers could handle it.
>
> Fixes: c965db444629 ("qed: Add support for debug data collection")
> Signed-off-by: Alexander Lobakin <alobakin@marvell.com>
> Signed-off-by: Igor Russkikh <irusskikh@marvell.com>
This is now how ethtool register dumps work.
It does not provide "human readable" versions of register data. Instead
it is supposed to be purely raw data and then userland utilities interpret
that data and can make it human readable based upon the driver name and
reg dump version.
Please fix your ethtool -d implementation to comply with this.
Thank you.
next prev parent reply other threads:[~2020-07-03 19:59 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-03 9:02 Alexander Lobakin
2020-07-03 19:59 ` David Miller [this message]
2020-07-03 23:57 ` Alexander Lobakin
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=20200703.125933.1255981278532631718.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=GR-everest-linux-l2@marvell.com \
--cc=aelior@marvell.com \
--cc=alobakin@marvell.com \
--cc=denis.bolotin@marvell.com \
--cc=irusskikh@marvell.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.kalderon@marvell.com \
--cc=netdev@vger.kernel.org \
/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®