netdev - Re: [PATCH net] wifi: avoid kernel-infoleak from struct iw

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0e3af232f15f62f2540a307ccb967c1ae5fdadbf.camel@sipsolutions.net>
Date: Thu, 08 Jan 2026 12:01:15 +0100
From: Johannes Berg <johannes@...solutions.net>
To: Eric Dumazet <edumazet@...gle.com>, "David S . Miller"
 <davem@...emloft.net>,  Jakub Kicinski	 <kuba@...nel.org>, Paolo Abeni
 <pabeni@...hat.com>
Cc: linux-wireless@...r.kernel.org, netdev@...r.kernel.org, 
	eric.dumazet@...il.com,
 syzbot+bfc7323743ca6dbcc3d3@...kaller.appspotmail.com, 
	stable@...r.kernel.org
Subject: Re: [PATCH net] wifi: avoid kernel-infoleak from struct iw_point

On Thu, 2026-01-08 at 10:19 +0000, Eric Dumazet wrote:
> 
> https://lore.kernel.org/netdev/695f83f3.050a0220.1c677c.0392.GAE@google.com/T/#u

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