Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230601112839.13799-1-dinghui@sangfor.com.cn>
 <135a45b2c388fbaf9db4620cb01b95230709b9ac.camel@gmail.com>
 <eed0cbf7-ff12-057e-e133-0ddf5e98ef68@sangfor.com.cn> <6110cf9f-c10e-4b9b-934d-8d202b7f5794@lunn.ch>
 <f7e23fe6-4d30-ef1b-a431-3ef6ec6f77ba@sangfor.com.cn> <6e28cea9-d615-449d-9c68-aa155efc8444@lunn.ch>
 <CAKgT0UdyykQL-BidjaNpjX99FwJTxET51U29q4_CDqmABUuVbw@mail.gmail.com>
 <ece228a3-5c31-4390-b6ba-ec3f2b6c5dcb@lunn.ch> <CAKgT0Uf+XaKCFgBRTn-viVsKkNE7piAuDpht=efixsAV=3JdFQ@mail.gmail.com>
 <44905acd-3ac4-cfe5-5e91-d182c1959407@sangfor.com.cn> <20230602225519.66c2c987@kernel.org>
 <5f0f2bab-ae36-8b13-2c6d-c69c6ff4a43f@sangfor.com.cn> <20230604104718.4bf45faf@kernel.org>
 <f6ad6281-df30-93cf-d057-5841b8c1e2e6@sangfor.com.cn> <20230605113915.4258af7f@kernel.org>
 <034f5393-e519-1e8d-af76-ae29677a1bf5@sangfor.com.cn>
In-Reply-To: <034f5393-e519-1e8d-af76-ae29677a1bf5@sangfor.com.cn>
From:   Alexander Duyck <alexander.duyck@gmail.com>
Date:   Thu, 8 Jun 2023 07:17:25 -0700
Message-ID: <CAKgT0UdX7cc-LVFowFrY7mSZMvN0xc+w+oH16GNrduLY-AddSA@mail.gmail.com>
Subject: Re: [PATCH net-next] net: ethtool: Fix out-of-bounds copy to user
To:     Ding Hui <dinghui@sangfor.com.cn>
Cc:     Jakub Kicinski <kuba@kernel.org>, Andrew Lunn <andrew@lunn.ch>,
        davem@davemloft.net, edumazet@google.com, pabeni@redhat.com,
        netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
        pengdonglin@sangfor.com.cn, huangcun@sangfor.com.cn
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Thu, Jun 8, 2023 at 2:06=E2=80=AFAM Ding Hui <dinghui@sangfor.com.cn> wr=
ote:
>
> On 2023/6/6 2:39, Jakub Kicinski wrote:
> > On Mon, 5 Jun 2023 11:39:59 +0800 Ding Hui wrote:
> >> Case 1:
> >> If the user len/n_stats is not zero, we will treat it as correct usage
> >> (although we cannot distinguish between the real correct usage and
> >> uninitialized usage). Return -EINVAL if current length exceed the one
> >> user specified.
> >
> > This assumes user will zero-initialize the value rather than do
> > something like:
> >
> >       buf =3D malloc(1 << 16); // 64k should always be enough
> >       ioctl(s, ETHTOOL_GSTATS, buf)
> >
> >       for (i =3D 0; i < buf.n_stats; i++)
> >               /* use stats */
> >
> > :(
> >
>
> Sorry for late.
>
> Now I'm not sure what can I do next besides reporting the issue.

Well as I said before. The issue points to a driver problem more than
anything else.

Normally the solution is to make it so that the counts don't
fluctuate. That mostly consists of providing strings equal to the
maximum count, and then 0 populating the data for any fields that
don't exist in the case of ethtool -S.

So for example in the case of igb which you had pointed out you could
take a look at ixgbe for inspiration on how to fix it since the two
drivers should be similar and one has the issue and one does not.