linux-kernel - Re: [PATCH net-next] net: ethtool: Fix out-of-bounds copy to user

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 5 Jun 2023 11:39:59 +0800
From:   Ding Hui <dinghui@...gfor.com.cn>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Alexander Duyck <alexander.duyck@...il.com>,
        Andrew Lunn <andrew@...n.ch>, davem@...emloft.net,
        edumazet@...gle.com, pabeni@...hat.com, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, pengdonglin@...gfor.com.cn,
        huangcun@...gfor.com.cn
Subject: Re: [PATCH net-next] net: ethtool: Fix out-of-bounds copy to user

On 2023/6/5 1:47, Jakub Kicinski wrote:
> On Sat, 3 Jun 2023 15:11:29 +0800 Ding Hui wrote:
>> Yes.
>>
>> I checked the others ioctl (e.g. ethtool_get_eeprom(), ethtool_get_features()),
>> and searched the git log of ethtool utility, so I think that is an implicit
>> rule and the check is missed in kernel where the patch involves.
>>
>> Without this rule, we cannot guarantee the safety of copy to user.
>>
>> Should we keep to be compatible with that incorrect userspace usage?
> 
> If such incorrect user space exists we do, if it doesn't we don't.
> Problem is that we don't know what exists out there.
> 
> Maybe we can add a pr_err_once() complaining about bad usage for now
> and see if anyone reports back that they are hitting it?
> 

How about this:

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.

Case 2:
If it is zero, we will treat it as incorrect usage, we can add a
pr_err_once() for it and keep to be compatible with it for a period of time.
At a suitable time in the future, this part can be removed by maintainers.

-- 
Thanks,
- Ding Hui