[PATCH] wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel

[PATCH] wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel

[Prasun Maiti]

iwpriv app uses iw_point structure to send data to Kernel. The iw_point
structure holds a pointer. For compatibility Kernel converts the pointer
as required for WEXT IOCTLs (SIOCIWFIRST to SIOCIWLAST). Some drivers
may use iw_handler_def.private_args to populate iwpriv commands instead
of iw_handler_def.private. For those case, the IOCTLs from
SIOCIWFIRSTPRIV to SIOCIWLASTPRIV will follow the path ndo_do_ioctl().
Accordingly when the filled up iw_point structure comes from 32 bit
iwpriv to 64 bit Kernel, Kernel will not convert the pointer and sends
it to driver. So, the driver may get the invalid data.

The pointer conversion for the IOCTLs (SIOCIWFIRSTPRIV to
SIOCIWLASTPRIV), which follow the path ndo_do_ioctl(), is mandatory.
This patch adds pointer conversion from 32 bit to 64 bit and vice versa,
if the ioctl comes from 32 bit iwpriv to 64 bit Kernel.

Signed-off-by: Prasun Maiti <prasunmaiti87@gmail.com>
Signed-off-by: Ujjal Roy <royujjal@gmail.com>
Tested-by: Dibyajyoti Ghosh <dibyajyotig@gmail.com>
---
 net/wireless/wext-core.c | 26 ++++++++++++++++++++++++--
 1 file changed, 24 insertions(+), 2 deletions(-)

--- a/net/wireless/wext-core.c
+++ b/net/wireless/wext-core.c
@@ -955,8 +955,30 @@ static int wireless_process_ioctl(struct net *net, struct ifreq *ifr,
 			return private(dev, iwr, cmd, info, handler);
 	}
 	/* Old driver API : call driver ioctl handler */
-	if (dev->netdev_ops->ndo_do_ioctl)
-		return dev->netdev_ops->ndo_do_ioctl(dev, ifr, cmd);
+	if (dev->netdev_ops->ndo_do_ioctl) {
+		if ((info->flags & IW_REQUEST_FLAG_COMPAT) &&
+				(cmd >= SIOCIWFIRSTPRIV && cmd <= SIOCIWLASTPRIV)) {
+			int ret = 0;
+			struct compat_iw_point *iwp_compat = (struct compat_iw_point *) &iwr->u.data;
+			struct iw_point *iwp = &iwr->u.data;
+			__u16 length = iwp_compat->length, flags = iwp_compat->flags;
+
+			iwp->pointer = compat_ptr(iwp_compat->pointer);
+			iwp->length = length;
+			iwp->flags = flags;
+
+			ret = dev->netdev_ops->ndo_do_ioctl(dev, ifr, cmd);
+
+			length = iwp->length;
+			flags = iwp->flags;
+			iwp_compat->pointer = ptr_to_compat(iwp->pointer);
+			iwp_compat->length = length;
+			iwp_compat->flags = flags;
+			return ret;
+		} else {
+			return dev->netdev_ops->ndo_do_ioctl(dev, ifr, cmd);
+		}
+	}
 	return -EOPNOTSUPP;
 }

--
1.9.1

Re: [PATCH] wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel

[Johannes Berg]

Hi,

I must say, this is a bit of a surprise - where is iwpriv actually
still relevant? What driver could this possibly matter for?

Anyway ...

> +	if (dev->netdev_ops->ndo_do_ioctl) {
> +		if ((info->flags & IW_REQUEST_FLAG_COMPAT) &&
> +				(cmd >= SIOCIWFIRSTPRIV && cmd <=
> SIOCIWLASTPRIV)) {

This has coding style issues, obviously.

Also, handling the non-compat case would allow you to return and reduce
indentation by one in the large code block that handles the compat.

> +			int ret = 0;
> +			struct compat_iw_point *iwp_compat = (struct compat_iw_point *) &iwr->u.data;
> +			struct iw_point *iwp = &iwr->u.data;
> +			__u16 length = iwp_compat->length, flags = iwp_compat->flags;
> +
> +			iwp->pointer = compat_ptr(iwp_compat->pointer);
> +			iwp->length = length;
> +			iwp->flags = flags;
> +
> +			ret = dev->netdev_ops->ndo_do_ioctl(dev, ifr, cmd);
> +
> +			length = iwp->length;
> +			flags = iwp->flags;
> +			iwp_compat->pointer = ptr_to_compat(iwp->pointer);
> +			iwp_compat->length = length;
> +			iwp_compat->flags = flags;

Why don't you just put another ifr/iwr on the stack, and use that to
pass things to the driver? This modify-in-place of 'iwp', which
requires loading all the variables first, seems very awkward to me.


johannes

Re: [PATCH] wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel

[Prasun Maiti]

Hi,

If a wireless driver uses "iw_handler_def.private_args" to populate
iwpriv command for private ioctls
but  handlers for private ioctls(iw_handler) of iw_handler_def.private
is set to NULL like "atmel" and "airo" wireless drivers.
For those case, the IOCTLs from SIOCIWFIRSTPRIV to SIOCIWLASTPRIV will
follow the path ndo_do_ioctl().
Accordingly when the filled up "iw_point" structure comes from 32 bit
iwpriv to 64 bit Kernel, Kernel will not convert the pointer and sends
it to driver. So, the driver may get the invalid data.

We have used another iwr (i.e; iwrp) to pass things to driver. Changes
are as follows. Please have look into this.

     diff --git a/net/wireless/wext-core.c b/net/wireless/wext-core.c
index 6250b1c..50583fb 100644
--- a/net/wireless/wext-core.c
+++ b/net/wireless/wext-core.c
@@ -958,8 +958,28 @@ static int wireless_process_ioctl(struct net
*net, struct ifreq *ifr,
            return private(dev, iwr, cmd, info, handler);
    }
    /* Old driver API : call driver ioctl handler */
-   if (dev->netdev_ops->ndo_do_ioctl)
-       return dev->netdev_ops->ndo_do_ioctl(dev, ifr, cmd);
+   if (dev->netdev_ops->ndo_do_ioctl) {
+       if (info->flags & IW_REQUEST_FLAG_COMPAT) {
+           int ret = 0;
+           struct iwreq iwrp;
+           struct compat_iw_point *iwp_compat =
+               (struct compat_iw_point *) &iwr->u.data;
+
+           strncpy(iwrp.ifr_ifrn.ifrn_name, iwr->ifr_ifrn.ifrn_name, IFNAMSIZ);
+           iwrp.u.data.pointer = compat_ptr(iwp_compat->pointer);
+           iwrp.u.data.length = iwp_compat->length;
+           iwrp.u.data.flags = iwp_compat->flags;
+
+           ret = dev->netdev_ops->ndo_do_ioctl(dev, (struct ifreq *)
&iwrp, cmd);
+
+           iwp_compat->pointer = ptr_to_compat(iwrp.u.data.pointer);
+           iwp_compat->length = iwrp.u.data.length;
+           iwp_compat->flags = iwrp.u.data.flags;
+           return ret;
+       } else {
+           return dev->netdev_ops->ndo_do_ioctl(dev, ifr, cmd);
+       }
+   }
    return -EOPNOTSUPP;
 }

Is it Ok?

Thanks,
Prasun

On Tue, May 31, 2016 at 3:55 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> Hi,
>
> I must say, this is a bit of a surprise - where is iwpriv actually
> still relevant? What driver could this possibly matter for?
>
> Anyway ...
>
>> +     if (dev->netdev_ops->ndo_do_ioctl) {
>> +             if ((info->flags & IW_REQUEST_FLAG_COMPAT) &&
>> +                             (cmd >= SIOCIWFIRSTPRIV && cmd <=
>> SIOCIWLASTPRIV)) {
>
> This has coding style issues, obviously.
>
> Also, handling the non-compat case would allow you to return and reduce
> indentation by one in the large code block that handles the compat.
>
>> +                     int ret = 0;
>> +                     struct compat_iw_point *iwp_compat = (struct compat_iw_point *) &iwr->u.data;
>> +                     struct iw_point *iwp = &iwr->u.data;
>> +                     __u16 length = iwp_compat->length, flags = iwp_compat->flags;
>> +
>> +                     iwp->pointer = compat_ptr(iwp_compat->pointer);
>> +                     iwp->length = length;
>> +                     iwp->flags = flags;
>> +
>> +                     ret = dev->netdev_ops->ndo_do_ioctl(dev, ifr, cmd);
>> +
>> +                     length = iwp->length;
>> +                     flags = iwp->flags;
>> +                     iwp_compat->pointer = ptr_to_compat(iwp->pointer);
>> +                     iwp_compat->length = length;
>> +                     iwp_compat->flags = flags;
>
> Why don't you just put another ifr/iwr on the stack, and use that to
> pass things to the driver? This modify-in-place of 'iwp', which
> requires loading all the variables first, seems very awkward to me.
>
>
> johannes



-- 
Thanks,
Prasun

Re: [PATCH] wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel

[Johannes Berg]

>      diff --git a/net/wireless/wext-core.c b/net/wireless/wext-core.c
> index 6250b1c..50583fb 100644
> --- a/net/wireless/wext-core.c
> +++ b/net/wireless/wext-core.c
> @@ -958,8 +958,28 @@ static int wireless_process_ioctl(struct net
> *net, struct ifreq *ifr,
>             return private(dev, iwr, cmd, info, handler);
>     }
>     /* Old driver API : call driver ioctl handler */
> -   if (dev->netdev_ops->ndo_do_ioctl)
> -       return dev->netdev_ops->ndo_do_ioctl(dev, ifr, cmd);
> +   if (dev->netdev_ops->ndo_do_ioctl) {
> +       if (info->flags & IW_REQUEST_FLAG_COMPAT) {
> +           int ret = 0;
> +           struct iwreq iwrp;
> +           struct compat_iw_point *iwp_compat =
> +               (struct compat_iw_point *) &iwr->u.data;

No need for the long cast - use (void *).

> +           strncpy(iwrp.ifr_ifrn.ifrn_name, iwr->ifr_ifrn.ifrn_name, 
> IFNAMSIZ);
> +           iwrp.u.data.pointer = compat_ptr(iwp_compat->pointer);
> +           iwrp.u.data.length = iwp_compat->length;
> +           iwrp.u.data.flags = iwp_compat->flags;

Maybe you should clear iwrp first?

> +           ret = dev->netdev_ops->ndo_do_ioctl(dev, (struct ifreq *)
> &iwrp, cmd);

Same here with the cast.

I'd blissfully forgotten how totally crufty this API is ... oh well.

> +           iwp_compat->pointer = ptr_to_compat(iwrp.u.data.pointer);
> +           iwp_compat->length = iwrp.u.data.length;
> +           iwp_compat->flags = iwrp.u.data.flags;
> +           return ret;
> +       } else {
> +           return dev->netdev_ops->ndo_do_ioctl(dev, ifr, cmd);





Please resend as a proper patch, with signed-off-by etc., and a commit
log explaining the problem and solution.

Thanks,
johannes

wext: making deprecation more visible

[Kalle Valo]

Johannes Berg <johannes@sipsolutions.net> writes:

> I'd blissfully forgotten how totally crufty this API is ... oh well.

Yesterday there was a user on IRC having problems with wext (I didn't
even bother to investigate what exactly) which was immediately solved by
switching to nl80211. But he had no idea that wext was depricated until
I told him.

I know we can't remove wext because of legacy applications but is there
anything more we can do to make the users aware that wext is depreciated
and really should be avoided? For example a onetime kernel warning? Or
is that too spammy? Anything else?

-- 
Kalle Valo

Re: wext: making deprecation more visible

[Johannes Berg]

> I know we can't remove wext because of legacy applications but is
> there anything more we can do to make the users aware that wext is
> depreciated and really should be avoided? For example a onetime
> kernel warning? Or is that too spammy? Anything else?

The problem is that wext is in this weird hybrid state where it's
really deprecated if you can use nl80211, but you are required to use
wext if you can't use nl80211. Now, we disabled wext-for-cfg80211 by
default, but it's still there and could be used for some cases.

We probably should try to fix things, but I realize that code that
never gets tested [1].

Maybe we could print a message in the special cfg80211-wext case, which
has a special case in wext-core to avoid creating all those iw_handler
tables?

johannes

[1] and yeah - people move to nl80211 once told, so there's evidently
very little incentive to keep using wext, so in reality people don't
really seem to have applications that only use wext even with pure
cfg80211 drivers ...

[PATCH] wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel

[Prasun Maiti]

iwpriv app uses iw_point structure to send data to Kernel. The iw_point
structure holds a pointer. For compatibility Kernel converts the pointer
as required for WEXT IOCTLs (SIOCIWFIRST to SIOCIWLAST). Some drivers
may use iw_handler_def.private_args to populate iwpriv commands instead
of iw_handler_def.private. For those case, the IOCTLs from
SIOCIWFIRSTPRIV to SIOCIWLASTPRIV will follow the path ndo_do_ioctl().
Accordingly when the filled up iw_point structure comes from 32 bit
iwpriv to 64 bit Kernel, Kernel will not convert the pointer and sends
it to driver. So, the driver may get the invalid data.

The pointer conversion for the IOCTLs (SIOCIWFIRSTPRIV to
SIOCIWLASTPRIV), which follow the path ndo_do_ioctl(), is mandatory.
This patch adds pointer conversion from 32 bit to 64 bit and vice versa,
if the ioctl comes from 32 bit iwpriv to 64 bit Kernel.

Signed-off-by: Prasun Maiti <prasunmaiti87@gmail.com>
Signed-off-by: Ujjal Roy <royujjal@gmail.com>
Tested-by: Dibyajyoti Ghosh <dibyajyotig@gmail.com>
---
 net/wireless/wext-core.c | 24 ++++++++++++++++++++++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/net/wireless/wext-core.c b/net/wireless/wext-core.c
index 6250b1c..a96dcc6 100644
--- a/net/wireless/wext-core.c
+++ b/net/wireless/wext-core.c
@@ -958,8 +958,28 @@ static int wireless_process_ioctl(struct net *net, struct ifreq *ifr,
 			return private(dev, iwr, cmd, info, handler);
 	}
 	/* Old driver API : call driver ioctl handler */
-	if (dev->netdev_ops->ndo_do_ioctl)
-		return dev->netdev_ops->ndo_do_ioctl(dev, ifr, cmd);
+	if (dev->netdev_ops->ndo_do_ioctl) {
+#ifdef CONFIG_COMPAT
+		if (info->flags & IW_REQUEST_FLAG_COMPAT) {
+			int ret = 0;
+			struct iwreq iwr_lcl;
+			struct compat_iw_point *iwp_compat = (void *) &iwr->u.data;
+
+			memcpy(&iwr_lcl, iwr, sizeof(struct iwreq));
+			iwr_lcl.u.data.pointer = compat_ptr(iwp_compat->pointer);
+			iwr_lcl.u.data.length = iwp_compat->length;
+			iwr_lcl.u.data.flags = iwp_compat->flags;
+
+			ret = dev->netdev_ops->ndo_do_ioctl(dev, (void *) &iwr_lcl, cmd);
+
+			iwp_compat->pointer = ptr_to_compat(iwr_lcl.u.data.pointer);
+			iwp_compat->length = iwr_lcl.u.data.length;
+			iwp_compat->flags = iwr_lcl.u.data.flags;
+			return ret;
+		} else
+#endif
+			return dev->netdev_ops->ndo_do_ioctl(dev, ifr, cmd);
+	}
 	return -EOPNOTSUPP;
 }

--
1.9.1

Re: [PATCH] wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel

[Johannes Berg]

On Mon, 2016-06-06 at 20:04 +0530, Prasun Maiti wrote:
> iwpriv app uses iw_point structure to send data to Kernel. The
> iw_point
> structure holds a pointer. For compatibility Kernel converts the
> pointer
> as required for WEXT IOCTLs (SIOCIWFIRST to SIOCIWLAST). Some drivers
> may use iw_handler_def.private_args to populate iwpriv commands
> instead
> of iw_handler_def.private. For those case, the IOCTLs from
> SIOCIWFIRSTPRIV to SIOCIWLASTPRIV will follow the path
> ndo_do_ioctl().
> Accordingly when the filled up iw_point structure comes from 32 bit
> iwpriv to 64 bit Kernel, Kernel will not convert the pointer and
> sends
> it to driver. So, the driver may get the invalid data.
> 
Applied.

johannes