Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S938725AbcJRUtk (ORCPT ); Tue, 18 Oct 2016 16:49:40 -0400 Received: from mail-wm0-f53.google.com ([74.125.82.53]:38904 "EHLO mail-wm0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933681AbcJRUta (ORCPT ); Tue, 18 Oct 2016 16:49:30 -0400 MIME-Version: 1.0 In-Reply-To: <20161017130412.GG29095@leverpostej> References: <1472221903-31181-1-git-send-email-mark.rutland@arm.com> <20161017130412.GG29095@leverpostej> From: Kees Cook Date: Tue, 18 Oct 2016 13:49:28 -0700 X-Google-Sender-Auth: pipzUtFS89Oe9hN6GsUhMvMmDhg Message-ID: Subject: Re: [kernel-hardening] [PATCH] lib: harden strncpy_from_user To: Mark Rutland Cc: "kernel-hardening@lists.openwall.com" , LKML , Andrew Morton Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1806 Lines: 40 On Mon, Oct 17, 2016 at 6:04 AM, Mark Rutland wrote: > On Fri, Aug 26, 2016 at 02:57:58PM -0400, Kees Cook wrote: >> On Fri, Aug 26, 2016 at 10:31 AM, Mark Rutland wrote: >> > The strncpy_from_user() accessor is effectively a copy_from_user() >> > specialised to copy strings, terminating early at a NUL byte if >> > possible. In other respects it is identical, and can be used to copy an >> > arbitrarily large buffer from userspace into the kernel. Conceptually, >> > it exposes a similar attack surface. >> > >> > As with copy_from_user(), we check the destination range when the kernel >> > is built with KASAN, but unlike copy_from_user() we do not check the >> > destination buffer when using HARDENED_USERCOPY. As strncpy_from_user() >> > calls get_user() in a loop, we must call check_object_size() explicitly. >> > >> > This patch adds this instrumentation to strncpy_from_user(), per the >> > same rationale as with the regular copy_from_user(). In the absence of >> > hardened usercopy this will have no impact as the instrumentation >> > expands to an empty static inline function. > > [...] > >> Ah, yes, good catch! (And to repeat what you mentioned to me in >> passing in the hall: there appear to be other users of get_user() in a >> loop in other places in the kernel that will likely need some >> attention too.) > > I was reminded of this as it just hit mainline; is it worth dropping a > TODO on the KSPP wiki? I suspect I won't have the time to delve much > further into this in the near term, and it might be a good intro task > for someone. Ah, right. I've updated the kernserc TODO list with this (recently the csum_* routines were pointed out), and added a bunch more TODOs that were in my notes. -Kees -- Kees Cook Nexus Security