netdev - Re: [PATCH] genetlink: fix unsigned int comparison with less than zero

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_iQpUw-PYmksL2StciJiM-8C+y3w9T_Vo4=pVKnjQzTwKvLg@mail.gmail.com>
Date:   Sat, 12 Nov 2016 21:25:05 -0800
From:   Cong Wang <xiyou.wangcong@...il.com>
To:     Johannes Berg <johannes@...solutions.net>
Cc:     Colin King <colin.king@...onical.com>,
        "David S . Miller" <davem@...emloft.net>,
        pravin shelar <pshelar@....org>,
        Wei Yongjun <weiyongjun1@...wei.com>,
        Florian Westphal <fw@...len.de>,
        Tycho Andersen <tycho.andersen@...onical.com>,
        Tom Herbert <tom@...bertland.com>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] genetlink: fix unsigned int comparison with less than zero

On Sat, Nov 12, 2016 at 1:37 PM, Johannes Berg
<johannes@...solutions.net> wrote:
> On Thu, 2016-11-10 at 09:11 -0800, Cong Wang wrote:
>> On Thu, Nov 10, 2016 at 7:57 AM, Colin King <colin.king@...onical.com
>> > wrote:
>> >
>> > From: Colin Ian King <colin.king@...onical.com>
>> >
>> > family->id is unsigned, so the less than zero check for
>> > failure return from idr_alloc is never true and so the error exit
>> > is never handled.  Instead, assign err and check if this is less
>> > than zero since this is a signed integer.
>>
>> Why family->id can't be just signed int? For me it should be.
>
> I suppose it could be, since family IDs are allocated in a 16-bit range
> anyway. But family IDs can also never actually be negative, so having
> an unsigned int in the struct makes sense too.

All idr_* API's accept int, rather than unsigned int. This is my point.