linux-kernel - Re: [PATCH] net: fix shift-out-of-bounds in nl802154_new

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, 06 Apr 2021 16:16:29 +0300
From:   Pavel Skripkin <paskripkin@...il.com>
To:     Alexander Aring <alex.aring@...il.com>
Cc:     Stefan Schmidt <stefan@...enfreihafen.org>,
        "David S. Miller" <davem@...emloft.net>,
        linux-wpan - ML <linux-wpan@...r.kernel.org>,
        "open list:NETWORKING [GENERAL]" <netdev@...r.kernel.org>,
        kernel list <linux-kernel@...r.kernel.org>,
        syzbot <syzbot+7bf7b22759195c9a21e9@...kaller.appspotmail.com>
Subject: Re: [PATCH] net: fix shift-out-of-bounds in nl802154_new_interface

On Tue, 2021-04-06 at 08:21 -0400, Alexander Aring wrote:
> Hi,
> 
> On Mon, 5 Apr 2021 at 15:58, Pavel Skripkin <paskripkin@...il.com>
> wrote:
> > 
> > syzbot reported shift-out-of-bounds in nl802154_new_interface.
> > The problem was in signed representation of enum nl802154_iftype
> > 
> > enum nl802154_iftype {
> >         /* for backwards compatibility TODO */
> >         NL802154_IFTYPE_UNSPEC = -1,
> > ...
> > 
> > Since, enum has negative value in it, objects of this type
> > will be represented as signed integer.
> > 
> >         type = nla_get_u32(info->attrs[NL802154_ATTR_IFTYPE]);
> > 
> > u32 will be casted to signed, which can cause negative value type.
> > 
> > Reported-by: syzbot+7bf7b22759195c9a21e9@...kaller.appspotmail.com
> > Signed-off-by: Pavel Skripkin <paskripkin@...il.com>
> 
> Yes, this patch will fix the issue but we discussed that the problem
> is deeper than such a fix. The real problem is that we are using a -1
> value which doesn't fit into the u32 netlink value and it gets
> converted back and forward which we should avoid.
> 

OK, thanks for feedback!

> 
> - Alex

With regards,
Pavel Skripkin