linux-kernel - Re: [PATCH] net: tehuti: don't process data if it has not been copied from userspace

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: <20170719.224901.2173661512386984465.davem@davemloft.net>
Date:   Wed, 19 Jul 2017 22:49:01 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     colin.king@...onical.com
Cc:     andy@...yhouse.net, netdev@...r.kernel.org,
        kernel-janitors@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] net: tehuti: don't process data if it has not been
 copied from userspace

From: Colin King <colin.king@...onical.com>
Date: Wed, 19 Jul 2017 18:46:59 +0100

> From: Colin Ian King <colin.king@...onical.com>
> 
> The array data is only populated with valid information from userspace
> if cmd != SIOCDEVPRIVATE, other cases the array contains garbage on
> the stack. The subsequent switch statement acts on a subcommand in
> data[0] which could be any garbage value if cmd is SIOCDEVPRIVATE which
> seems incorrect to me.  Instead, just return EOPNOTSUPP for the case
> where cmd == SIOCDEVPRIVATE to avoid this issue.
> 
> As a side note, I suspect that the original intention of the code
> was for this ioctl to work just for cmd == SIOCDEVPRIVATE (and the
> current logic is reversed). However, I don't wont to change the current
> semantics in case any userspace code relies on this existing behaviour.
> 
> Detected by CoverityScan, CID#139647 ("Uninitialized scalar variable")
> 
> Signed-off-by: Colin Ian King <colin.king@...onical.com>

Yeah this is the safest change for now, applied.

Francois added the register address range checking a year after the
driver was added, so maybe someone used this facility.

It should have been done via ethtool getregs...