Hi! On Mon, 2021-04-12 at 07:45 -0400, Alexander Aring wrote: > Hi, > > On Mon, 12 Apr 2021 at 06:58, Pavel Skripkin <paskripkin@xxxxxxxxx> > wrote: > > > > syzbot reported WARNING in ieee802154_del_device. The problem > > was in uninitialized mutex. In case of NL802154_IFTYPE_MONITOR > > mutex won't be initialized, but ieee802154_del_device() accessing > > it. > > > > Reported-by: syzbot+bf8b5834b7ec229487ce@xxxxxxxxxxxxxxxxxxxxxxxxx > > Signed-off-by: Pavel Skripkin <paskripkin@xxxxxxxxx> > > --- > > net/mac802154/iface.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/net/mac802154/iface.c b/net/mac802154/iface.c > > index 1cf5ac09edcb..be8d2a02c882 100644 > > --- a/net/mac802154/iface.c > > +++ b/net/mac802154/iface.c > > @@ -599,6 +599,7 @@ ieee802154_setup_sdata(struct > > ieee802154_sub_if_data *sdata, > > > > break; > > case NL802154_IFTYPE_MONITOR: > > + mutex_init(&sdata->sec_mtx); > > sdata->dev->needs_free_netdev = true; > > sdata->dev->netdev_ops = &mac802154_monitor_ops; > > wpan_dev->promiscuous_mode = true; > > yes that will fix the issue, but will let the user notify that > setting > any security setting is supported by monitors which is not the case. > There are patches around which should return -EOPNOTSUPP for > monitors. > However we might support it in future to let the kernel encrypt air > frames, but this isn't supported yet and the user should be aware > that > it isn't. > Thank you for your feedback. I am still not familiar with net internals yet :) Next time I ll try to go deeper. Thanks! > - Alex With regards, Pavel Skripkin
