netdev - RE: natsemi.c ioctl fix or mii register access

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <010200463BAAFF45926C5BFD8E21F515FD50C7@cos-us-mb01.cos.agilent.com>
Date:	Tue, 27 May 2008 10:29:09 -0600
From:	<glenn_engel@...lent.com>
To:	<romieu@...zoreil.com>
Cc:	<jgarzik@...ox.com>, <netdev@...r.kernel.org>
Subject: RE: natsemi.c ioctl fix or mii register access

[...]
> > I suppose this copy could be done in dev.c for these ioctls but it
> would
> > also need to tweak the ifru_data field to point to local storage
> > before/after the ioctl calls.  Perhaps this was the original intent
> and
> > was not noticed since ethtool doesn't use these ioctls. I just
> assumed
> > the natsemi driver was the odd duck but perhaps none of them work
> with
> > these ioctls at this point.
> 
> The type-casting is a bit confusing at times but these ioctls work
> rather
> well in real life, with mii-tool for instance.
> 

OK, I see what you mean.  Even though the ifru_data field is a __user* pointer and nominally 4 bytes long, the mii-tool program is treating it as an 8 byte mii_ioctl_data info structure and ignoring the fact it's a pointer and relying on the fact that other fields in the union are 8 or more bytes long.

Now that I understand the usage I'm wondering if there was a way for me to intuit that the __user* pointer was not really intended to be a user space pointer other than finding the mii-tool source?

Thanks for clearing this up.

--
Glenn

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html