SIOCETHTOOL ioctl() and a corrupted cmd argument

SIOCETHTOOL ioctl() and a corrupted cmd argument

[Patrick R. McManus]

Hello,

this is odd.

My problem is with the cmd argument to a driver's ioctl() handler
getting modified when the caller is non root.

I have a 2.4.19era kernel and am running the e1000 driver, as a
module, from the 2.4.20 kernel. (drivers previous to 4.4.12 tended to
keep resetting themselves on me.) 

my userspace code make a call that looks like this

        struct ethtool_cmd ec;
        int fd;
        int rv = -1;

        memset (&ifr,0,sizeof(ifr));
        strncpy (ifr.ifr_name, getName(),IFNAMSIZ);
        fd = socket (PF_INET,SOCK_DGRAM,0);
        ifr.ifr_data = (char *) &ec;
        ec.cmd = ETHTOOL_GSET;

        fprintf (stderr,"SIOCETHTOOL is %X\n",SIOCETHTOOL);
        if (ioctl(fd, SIOCETHTOOL, &ifr) >=0)

stderr always prints: SIOCETHTOOL is 8946

when I run the userspace code as root the ioctl succeeds, when I run
it as an unpriv'd user it fails.

So I annotated the driver by adding to e1000_ioctl:

     printk(KERN_INFO "general ioctl cmd %X, magic %X\n",cmd,SIOCETHTOOL);

as root I get the expected
Mar  5 15:53:33 mcmanus kernel: general ioctl cmd 8946, magic 8946

as a regular user I get 
Mar  5 15:46:57 mcmanus kernel: general ioctl cmd 89F0, magic 8946

can someone help me with the chain to look at for why the cmd value
might be getting modified?

-Patrick

Re: SIOCETHTOOL ioctl() and a corrupted cmd argument

[Patrick R. McManus]

[Patrick R. McManus: Mar 05 16:00]

> as a regular user I get 
> Mar  5 15:46:57 mcmanus kernel: general ioctl cmd 89F0, magic 8946
> 

turns out, as I had expected, my report is bogus.. this ioctl is a
fallback after the siocethtool fails. the driver do_ioctl() never gets
invoked at all when the ioctl() is invoked without being root.

this would be because in net/core/dev.c dev_ioctl() they are filtered out:

        case SIOCETHTOOL:
        case SIOCGMIIPHY:
        case SIOCGMIIREG:
            if (!capable(CAP_NET_ADMIN))
                return -EPERM;

but SIOCETHTOOL shouldn't need perms, right? it has some functionality
that needs it and some that doesn't, and the driver sorts it
out.. there isn't a GIOCETHTOOL at all..

#define ETHTOOL_GSET        0x00000001 /* Get settings. */
#define ETHTOOL_SSET        0x00000002 /* Set settings, privileged. */

Re: SIOCETHTOOL ioctl() and a corrupted cmd argument

[Jeff Garzik]

On Wed, Mar 05, 2003 at 04:32:05PM -0500, Patrick R. McManus wrote:
> but SIOCETHTOOL shouldn't need perms, right? it has some functionality
> that needs it and some that doesn't, and the driver sorts it
> out.. there isn't a GIOCETHTOOL at all..
> 
> #define ETHTOOL_GSET        0x00000001 /* Get settings. */
> #define ETHTOOL_SSET        0x00000002 /* Set settings, privileged. */


You are correct that comment is misleading... all ethtool does current
requiring CAP_NET_ADMIN.  This is one of the costs of lumping things
under one ioctl, rather than constantly using new ioctls.

It is certainly possible (and reasonable) that a future kernel peeks at
the ioctl and then conditionally checks privs, but this is not currently
the case.

	Jeff