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>
In-Reply-To: <6e28cea9-d615-449d-9c68-aa155efc8444@lunn.ch>
From:   Alexander Duyck <alexander.duyck@gmail.com>
Date:   Fri, 2 Jun 2023 09:01:34 -0700
Message-ID: <CAKgT0UdyykQL-BidjaNpjX99FwJTxET51U29q4_CDqmABUuVbw@mail.gmail.com>
Subject: Re: [PATCH net-next] net: ethtool: Fix out-of-bounds copy to user
To:     Andrew Lunn <andrew@lunn.ch>
Cc:     Ding Hui <dinghui@sangfor.com.cn>, davem@davemloft.net,
        edumazet@google.com, kuba@kernel.org, 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 Fri, Jun 2, 2023 at 8:42=E2=80=AFAM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > > Also, RTNL should be held during the time both calls are made into th=
e
> > > driver. So nothing from userspace should be able to get in the middle
> > > of these calls to change the number of queues.
> > >
> >
> > The RTNL lock is already be held during every each ioctl in dev_ethtool=
().
> >
> >     rtnl_lock();
> >     rc =3D __dev_ethtool(net, ifr, useraddr, ethcmd, state);
> >     rtnl_unlock();
>
> Yes, exactly. So the kernel should be safe from buffer overruns.
>
> Userspace will not get more than it asked for. It might get less, and
> it could be different to the previous calls. But i'm not aware of
> anything which says anything about the consistency between different
> invocations of ethtool -S.

The problem is the userspace allocation ends up requiring we make two
calls into the stack. So it takes the lock once to get the count,
performs the allocation, and then calls into ethtool again taking the
lock and by then the value may have changed.

Within each call it is held the entire time, but the userspace has to
make two calls. So in between the two the number of rings could
potentially change.

What this change is essentially doing is clamping the copied data to
the lesser of the current value versus the value when the userspace
was allocated. However I am wondering now if we shouldn't just update
the size value and return that as some sort of error for the userspace
to potentially reallocate and repeat until it has the right size.