On Thu, 2026-01-08 at 10:19 +0000, Eric Dumazet wrote:
https://lore.kernel.org/netdev/695f83f3.050a0220.1c677c.0392.GAE@google.com/...
That wasn't the easiest bit to follow (for me anyway), so for anyone else wanting to follow along, here's my interpretation of what happens:
+++ b/net/wireless/wext-core.c @@ -1101,6 +1101,10 @@ static int compat_standard_call(struct net_device *dev, return ioctl_standard_call(dev, iwr, cmd, info, handler); iwp_compat = (struct compat_iw_point *) &iwr->u.data;
- /* struct iw_point has a 32bit hole on 64bit arches. */
- memset(&iwp, 0, sizeof(iwp));
- iwp.pointer = compat_ptr(iwp_compat->pointer); iwp.length = iwp_compat->length; iwp.flags = iwp_compat->flags;
This all looks mostly fine locally, even for the compat code, i.e. for a 32-bit task on the 64-bit machine. The iwp is created here and is given to ioctl_standard_iw_point(), which crucially then for some requests (according to IW_DESCR_FLAG_EVENT) passes it to wireless_send_event().
This then can creates _two_ events, one for 32-bit tasks and one for 64- bit tasks, and the 64-bit one will have the "struct iw_point" starting from "length", excluding "pointer" but including the padding at the end... The layout is further described in the "The problem for 64/32 bit." comment in wext-core.c
I don't think this can happen for the compat_private_call() part since no events are generated there, but fixing it there as well is definitely better (and who knows what random drivers might do in priv ioctls.)
johannes