[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jKL13qdCBet3yqpc3vLYh_LifBACzL+NP8n-A+E8RMZXw@mail.gmail.com>
Date: Mon, 29 Sep 2014 12:41:12 -0700
From: Kees Cook <keescook@...omium.org>
To: David Laight <David.Laight@...lab.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>,
Jason Wang <jasowang@...hat.com>,
Zhi Yong Wu <wuzhy@...ux.vnet.ibm.com>,
"Michael S. Tsirkin" <mst@...hat.com>,
Tom Herbert <therbert@...gle.com>,
Masatake YAMATO <yamato@...hat.com>, Xi Wang <xii@...gle.com>,
stephen hemminger <stephen@...workplumber.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH] tun: make sure interface usage can not overflow
On Mon, Sep 29, 2014 at 4:04 AM, David Laight <David.Laight@...lab.com> wrote:
> From: Kees Cook
>> This makes the size argument a const, since it is always populated by
>> the caller.
>
> There is almost no point making parameters 'const.
> ('const foo *' makes sense).
>
>> Additionally double-checks to make sure the copy_from_user
>> can never overflow, keeping CONFIG_DEBUG_STRICT_USER_COPY_CHECKS happy:
>>
>> In function 'copy_from_user',
>> inlined from '__tun_chr_ioctl' at drivers/net/tun.c:1871:7:
>> ... copy_from_user() buffer size is not provably correct
>
> If 'ifreq_len' could be too big then you want to error the ioctl, not panic.
> If it can't be too big you don't need the check.
The ifreq_len comes from the callers, and is the output of "sizeof"
which is const. Changing the function parameter to "const" means any
changes made in the future where the incoming value isn't const, the
compiler will throw a warning.
-Kees
--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists