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

Message-ID: <CAM_iQpUo-Rp5OhbtLVGOG_HPYZYuPXeqVMZ3ip=VMUJ42Cg4PQ@mail.gmail.com>
Date:   Mon, 23 Jul 2018 13:37:22 -0700
From:   Cong Wang <xiyou.wangcong@...il.com>
To:     Tariq Toukan <tariqt@...lanox.com>
Cc:     David Miller <davem@...emloft.net>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        eranbe@...lanox.com
Subject: Re: [PATCH net-next] net: remove redundant input checks in
 SIOCSIFTXQLEN case of dev_ifsioc

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.

Thanks.