mbox series

[wpan,00/17] ieee802154: syzbot fixes

Message ID 20210228151817.95700-1-aahringo@redhat.com
Headers show
Series ieee802154: syzbot fixes | expand

Message

Alexander Aring Feb. 28, 2021, 3:18 p.m. UTC
Hi,

this patch series contains fixes found by syzbot for nl802154 and a
memory leak each time we receiving a skb for monitor interfaces.

The first three patches are misc fixes, all others are to forbid monitor
interfaces to access security mib values which are never initialized for
monitor interfaces yet. We never supported such handling but I can
imagine that we can use security mib for monitor interfaces to decrypt
802.15.4 frames by the Linux kernel and the RAW sockets can see
plaintext then. However it's a possibility for an new feature to check in
due courses.

- Alex

Alexander Aring (17):
  net: ieee802154: make shift exponent unsigned
  net: ieee802154: fix memory leak when deliver monitor skbs
  net: ieee802154: nl-mac: fix check on panid
  net: ieee802154: forbid monitor for set llsec params
  net: ieee802154: stop dump llsec keys for monitors
  net: ieee802154: forbid monitor for add llsec key
  net: ieee802154: forbid monitor for del llsec key
  net: ieee802154: stop dump llsec devs for monitors
  net: ieee802154: forbid monitor for add llsec dev
  net: ieee802154: forbid monitor for del llsec dev
  net: ieee802154: stop dump llsec devkeys for monitors
  net: ieee802154: forbid monitor for add llsec devkey
  net: ieee802154: forbid monitor for del llsec devkey
  net: ieee802154: stop dump llsec seclevels for monitors
  net: ieee802154: forbid monitor for add llsec seclevel
  net: ieee802154: forbid monitor for del llsec seclevel
  net: ieee802154: stop dump llsec params for monitors

 net/ieee802154/nl-mac.c   |  7 ++---
 net/ieee802154/nl802154.c | 54 ++++++++++++++++++++++++++++++++++++++-
 net/mac802154/rx.c        |  2 ++
 3 files changed, 59 insertions(+), 4 deletions(-)

Comments

Alexander Aring March 1, 2021, 3:16 a.m. UTC | #1
Hi Stefan,

On Sun, 28 Feb 2021 at 10:21, Alexander Aring <aahringo@redhat.com> wrote:
>

> This patch adds a missing consume_skb() when deliver a skb to upper

> monitor interfaces of a wpan phy.

>

> Reported-by: syzbot+44b651863a17760a893b@syzkaller.appspotmail.com

> Signed-off-by: Alexander Aring <aahringo@redhat.com>

> ---

>  net/mac802154/rx.c | 2 ++

>  1 file changed, 2 insertions(+)

>

> diff --git a/net/mac802154/rx.c b/net/mac802154/rx.c

> index b8ce84618a55..18abc1f49323 100644

> --- a/net/mac802154/rx.c

> +++ b/net/mac802154/rx.c

> @@ -244,6 +244,8 @@ ieee802154_monitors_rx(struct ieee802154_local *local, struct sk_buff *skb)

>                         sdata->dev->stats.rx_bytes += skb->len;

>                 }

>         }

> +

> +       consume_skb(skb);


Please drop this patch. It's not correct. I will look next weekend at
this one again.
The other patches should be fine, I hope.

- Alex
Stefan Schmidt March 2, 2021, 12:43 p.m. UTC | #2
Hello Alex.

On 01.03.21 04:16, Alexander Aring wrote:
> Hi Stefan,

> 

> On Sun, 28 Feb 2021 at 10:21, Alexander Aring <aahringo@redhat.com> wrote:

>>

>> This patch adds a missing consume_skb() when deliver a skb to upper

>> monitor interfaces of a wpan phy.

>>

>> Reported-by: syzbot+44b651863a17760a893b@syzkaller.appspotmail.com

>> Signed-off-by: Alexander Aring <aahringo@redhat.com>

>> ---

>>   net/mac802154/rx.c | 2 ++

>>   1 file changed, 2 insertions(+)

>>

>> diff --git a/net/mac802154/rx.c b/net/mac802154/rx.c

>> index b8ce84618a55..18abc1f49323 100644

>> --- a/net/mac802154/rx.c

>> +++ b/net/mac802154/rx.c

>> @@ -244,6 +244,8 @@ ieee802154_monitors_rx(struct ieee802154_local *local, struct sk_buff *skb)

>>                          sdata->dev->stats.rx_bytes += skb->len;

>>                  }

>>          }

>> +

>> +       consume_skb(skb);

> 

> Please drop this patch. It's not correct. I will look next weekend at

> this one again.

> The other patches should be fine, I hope.


Thanks for the heads up. I dropped this patch and will take a look at 
the rest of the  series today or tomorrow.

regards
Stefan Schmidt