Hello Alex.
On 28.02.21 16:18, Alexander Aring wrote:
This patch changes the iftype type variable to unsigned that it can
never be reach a negative value.
Reported-by: syzbot+7bf7b22759195c9a2...@syzkaller.appspotmail.com
Signed-off-by: Alexander Aring <aahri...@redhat.com>
---
net/ieee802154/nl802154.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
index e9e4652cd592..3ee09f6d13b7 100644
--- a/net/ieee802154/nl802154.c
+++ b/net/ieee802154/nl802154.c
@@ -898,8 +898,8 @@ static int nl802154_get_interface(struct sk_buff *skb,
struct genl_info *info)
static int nl802154_new_interface(struct sk_buff *skb, struct genl_info *info)
{
struct cfg802154_registered_device *rdev = info->user_ptr[0];
- enum nl802154_iftype type = NL802154_IFTYPE_UNSPEC;
__le64 extended_addr = cpu_to_le64(0x0000000000000000ULL);
+ u32 type = NL802154_IFTYPE_UNSPEC;
/* TODO avoid failing a new interface
* creation due to pending removal?
I am concerned about this one. Maybe you can shed some light on it.
NL802154_IFTYPE_UNSPEC is -1 which means the u32 will not hold this
value, but something at the end of the range for u32.
There is a path (info->attrs[NL802154_ATTR_IFTYPE] is not true) where we
put type forward to rdev_add_virtual_intf() with its changed value but
it would expect and enum which could hold -1 for UNSPEC.
regards
Stefan Schmidt
