Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <f8af54cece4150b2a0ac7db4e73bfcda36da5555.camel@gmail.com>
Subject: Re: [PATCH] net: fix shift-out-of-bounds in nl802154_new_interface
From:   Pavel Skripkin <paskripkin@gmail.com>
To:     Alexander Aring <alex.aring@gmail.com>
Cc:     Stefan Schmidt <stefan@datenfreihafen.org>,
        "David S. Miller" <davem@davemloft.net>,
        linux-wpan - ML <linux-wpan@vger.kernel.org>,
        "open list:NETWORKING [GENERAL]" <netdev@vger.kernel.org>,
        kernel list <linux-kernel@vger.kernel.org>,
        syzbot <syzbot+7bf7b22759195c9a21e9@syzkaller.appspotmail.com>
Date:   Tue, 06 Apr 2021 16:16:29 +0300
In-Reply-To: <CAB_54W7R-27cwOTUw1Db1+kbWTMTtRn0X2EW1_9nKuiAWpLFfA@mail.gmail.com>
References: <20210405195744.19386-1-paskripkin@gmail.com>
         <CAB_54W7R-27cwOTUw1Db1+kbWTMTtRn0X2EW1_9nKuiAWpLFfA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.38.4 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

On Tue, 2021-04-06 at 08:21 -0400, Alexander Aring wrote:
> Hi,
> 
> On Mon, 5 Apr 2021 at 15:58, Pavel Skripkin <paskripkin@gmail.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@syzkaller.appspotmail.com
> > Signed-off-by: Pavel Skripkin <paskripkin@gmail.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