netdev - Re: [PATCH net-next] net: remove redundant input checks in SIOCSIFTXQLEN case of dev

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] [day] [month] [year] [list]

Date:   Tue, 24 Jul 2018 11:35:07 +0300
From:   Tariq Toukan <tariqt@...lanox.com>
To:     David Miller <davem@...emloft.net>, xiyou.wangcong@...il.com
Cc:     tariqt@...lanox.com, netdev@...r.kernel.org, eranbe@...lanox.com
Subject: Re: [PATCH net-next] net: remove redundant input checks in
 SIOCSIFTXQLEN case of dev_ifsioc



On 24/07/2018 12:00 AM, David Miller wrote:
> From: Cong Wang <xiyou.wangcong@...il.com>
> Date: Mon, 23 Jul 2018 13:37:22 -0700
> 
>> On Sun, Jul 22, 2018 at 12:29 AM Tariq Toukan <tariqt@...lanox.com> wrote:
>>>
>>>
>>>
>>> On 19/07/2018 8:21 PM, Cong Wang wrote:
>>>> On Thu, Jul 19, 2018 at 7:50 AM Tariq Toukan <tariqt@...lanox.com> wrote:
>>>>> --- a/net/core/dev_ioctl.c
>>>>> +++ b/net/core/dev_ioctl.c
>>>>> @@ -282,14 +282,7 @@ static int dev_ifsioc(struct net *net, struct ifreq *ifr, unsigned int cmd)
>>>>>                   return dev_mc_del_global(dev, ifr->ifr_hwaddr.sa_data);
>>>>>
>>>>>           case SIOCSIFTXQLEN:
>>>>> -               if (ifr->ifr_qlen < 0)
>>>>> -                       return -EINVAL;
>>>>
>>>> Are you sure we can remove this if check too?
>>>>
>>>> The other one is safe to remove.
>>>>
>>>
>>> Hmm, let's see:
>>> dev_change_tx_queue_len gets unsigned long new_len, any negative value
>>> passed is interpreted as a very large number, then we test:
>>> if (new_len != (unsigned int)new_len)
>>>
>>> This test returns true if range of unsigned long is larger than range of
>>> unsigned int. AFAIK these ranges are Arch dependent and there is no
>>> guarantee this holds.
>>
>> I am not sure either, you probably have to give it a test.
>> And at least, explain it in changelog if you still want to remove it.
> 
> On 64-bit we will fail with -ERANGE.  The 32-bit int ifr_qlen will be sign
> extended to 64-bits when it is passed into dev_change_tx_queue_len(). And
> then for negative values this test triggers:
> 
> 	if (new_len != (unsigned int)new_len)
> 		return -ERANGE;
> 
> because:
> 	if (0xffffffffWHATEVER != 0x00000000WHATEVER)
> 
> On 32-bit the signed value will be accepted, changing behavior.
> 
> I think, therefore, that the < 0 check should be retained.

Agree.
I am sending a re-spin.

> 
> Thank you.
>