Netdev List
 help / color / mirror / Atom feed
From: Alexander Aring <aring@mojatatu.com>
To: Stefan Schmidt <stefan@datenfreihafen.org>
Cc: David Miller <davem@davemloft.net>,
	yuehaibing@huawei.com, h.morris@cascoda.com,
	alex.aring@gmail.com, linux-kernel@vger.kernel.org,
	netdev@vger.kernel.org, linux-wpan@vger.kernel.org
Subject: Re: [PATCH net-next] ieee802154: ca8210: fix possible u8 overflow in ca8210_rx_done
Date: Tue, 11 Dec 2018 10:23:45 -0500	[thread overview]
Message-ID: <20181211152345.gdlu6rnzng3kddgo@x220t> (raw)
In-Reply-To: <87dbac94-8b2e-8cef-5166-8c130529ceb9@datenfreihafen.org>

Hi Stefan,

On Tue, Dec 11, 2018 at 09:26:37AM +0100, Stefan Schmidt wrote:
> Hello Dave.
> 
> On 11.12.18 07:01, David Miller wrote:
> > From: YueHaibing <yuehaibing@huawei.com>
> > Date: Tue, 11 Dec 2018 11:13:39 +0800
> > 
> >> gcc warning this:
> >>
> >> drivers/net/ieee802154/ca8210.c:730:10: warning:
> >>  comparison is always false due to limited range of data type [-Wtype-limits]
> >>
> >> 'len' is u8 type, we get it from buf[1] adding 2, which can overflow.
> >> This patch change the type of 'len' to unsigned int to avoid this,also fix
> >> the gcc warning.
> >>
> >> Fixes: ded845a781a5 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver")
> >> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> > 
> > WPAN maintainers, I am assuming that as maintainers you will be
> > picking this up and sending it to me.
> 
> That's correct. On driver patches I always wait 2 days or so to give the
> driver maintainer a chance to reply before I go ahead and apply it.
> 
> I will take this one directly now and do some smoke testing. It will
> come together with another fix as pull request to you.
>

If this "len" is related to the frame (error message says packet) length when
"rx_done()" what the function name tells me, I think what the drivers
is looking for is:

ieee802154_is_valid_psdu_len() plus maybe before calculation of the length
depends what else the transceiver put as payload.

side note:

All drivers need to check if the length is valid as this is transmitted
in the PHY header and even not portected by CRC which is only for the
MAC payload. I had some ugly bufferoverflows expierence with some
at86rf2xx while my microwave was on.

- Alex

  reply	other threads:[~2018-12-11 15:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-11  3:13 [PATCH net-next] ieee802154: ca8210: fix possible u8 overflow in ca8210_rx_done YueHaibing
2018-12-11  6:01 ` David Miller
2018-12-11  8:26   ` Stefan Schmidt
2018-12-11 15:23     ` Alexander Aring [this message]
2018-12-11  8:39 ` Stefan Schmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181211152345.gdlu6rnzng3kddgo@x220t \
    --to=aring@mojatatu.com \
    --cc=alex.aring@gmail.com \
    --cc=davem@davemloft.net \
    --cc=h.morris@cascoda.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wpan@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=stefan@datenfreihafen.org \
    --cc=yuehaibing@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox