netdev - Re: [Patch net 0/3] idr: fix overflow cases on 32-bit CPU

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:   Mon, 1 Jul 2019 20:12:18 -0700
From:   Cong Wang <xiyou.wangcong@...il.com>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     David Miller <davem@...emloft.net>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Davide Caratti <dcaratti@...hat.com>,
        Chris Mi <chrism@...lanox.com>
Subject: Re: [Patch net 0/3] idr: fix overflow cases on 32-bit CPU

On Mon, Jul 1, 2019 at 7:37 PM Matthew Wilcox <willy@...radead.org> wrote:
>
> On Mon, Jul 01, 2019 at 07:16:00PM -0700, David Miller wrote:
> > From: Cong Wang <xiyou.wangcong@...il.com>
> > Date: Fri, 28 Jun 2019 11:03:40 -0700
> >
> > > idr_get_next_ul() is problematic by design, it can't handle
> > > the following overflow case well on 32-bit CPU:
> > >
> > > u32 id = UINT_MAX;
> > > idr_alloc_u32(&id);
> > > while (idr_get_next_ul(&id) != NULL)
> > >  id++;
> > >
> > > when 'id' overflows and becomes 0 after UINT_MAX, the loop
> > > goes infinite.
> > >
> > > Fix this by eliminating external users of idr_get_next_ul()
> > > and migrating them to idr_for_each_entry_continue_ul(). And
> > > add an additional parameter for these iteration macros to detect
> > > overflow properly.
> > >
> > > Please merge this through networking tree, as all the users
> > > are in networking subsystem.
> >
> > Series applied, thanks Cong.
>
> Ugh, I don't even get the weekend to reply?
>
> I think this is just a bad idea.  It'd be better to apply the conversion
> patches to use XArray than fix up this crappy interface.  I didn't
> reply before because I wanted to check those patches still apply and
> post them as part of the response.  Now they're definitely broken and
> need to be redone.

You can always do refactoring for net-next/linux-next. It is never late
for it.

Thanks.