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

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

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 499 bytes --]

I'm looking at commit 3d5fdff46c4b as part of the stable process.

The path it touches is only used for drivers that don't describe their
private wext handlers, right?  So how can we know that the private
ioctl is using the iw_point structure and not one of the other types in
union iwreq_data?  Doesn't this result in a regression when another
type is being used?

Ben.

-- 
Ben Hutchings
Beware of bugs in the above code;
I have only proved it correct, not tried it. - Donald Knuth

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Johannes Berg]

On Sun, 2016-08-07 at 17:49 +0100, Ben Hutchings wrote:
> I'm looking at commit 3d5fdff46c4b as part of the stable process.
> 
> The path it touches is only used for drivers that don't describe
> their private wext handlers, right?  So how can we know that the
> private ioctl is using the iw_point structure and not one of the
> other types in union iwreq_data?  Doesn't this result in a regression
> when another type is being used?
> 

Crap, that's good point. I'll revert the patch.

Fortunately this code path is never actually used. The only "mainline"
driver that appears to use it is staging/wilc1000.

I wonder if we should just remove it entirely. Yes, it'd break that
staging driver to some extent, but it's clearly an unsafe code path.

Prasun, did you need this for the mwifiex wext ioctl support that was
shot down anyway?

johannes