Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755721AbaDNRto (ORCPT ); Mon, 14 Apr 2014 13:49:44 -0400 Received: from mail-ob0-f172.google.com ([209.85.214.172]:54966 "EHLO mail-ob0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751412AbaDNRtG (ORCPT ); Mon, 14 Apr 2014 13:49:06 -0400 MIME-Version: 1.0 In-Reply-To: References: <20140414171114.GA31384@www.outflux.net>

Date: Mon, 14 Apr 2014 10:49:05 -0700 X-Google-Sender-Auth: VHFrS_SWC_CXXNSUijI0tYHAW0I Message-ID: Subject: Re: [PATCH] seccomp: fix memory leak on filter attach From: Kees Cook To: Alexei Starovoitov Cc: James Morris , LKML , Masami Ichikawa , Will Drewry , Josh Triplett , Rashika Kheria , "David S. Miller" , Eric Paris , Network Development Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 14, 2014 at 10:35 AM, Alexei Starovoitov wrote: > On Mon, Apr 14, 2014 at 10:26 AM, Kees Cook wrote: >> On Mon, Apr 14, 2014 at 10:17 AM, Alexei Starovoitov wrote: >>> On Mon, Apr 14, 2014 at 10:11 AM, Kees Cook wrote: >>>> This sets the correct error code when final filter memory is unavailable, >>>> and frees the raw filter no matter what. >>>> >>>> unreferenced object 0xffff8800d6ea4000 (size 512): >>>> comm "sshd", pid 278, jiffies 4294898315 (age 46.653s) >>>> hex dump (first 32 bytes): >>>> 21 00 00 00 04 00 00 00 15 00 01 00 3e 00 00 c0 !...........>... >>>> 06 00 00 00 00 00 00 00 21 00 00 00 00 00 00 00 ........!....... >>>> backtrace: >>>> [] kmemleak_alloc+0x4e/0xb0 >>>> [] __kmalloc+0x280/0x320 >>>> [] prctl_set_seccomp+0x11e/0x3b0 >>>> [] SyS_prctl+0x3bb/0x4a0 >>>> [] system_call_fastpath+0x1a/0x1f >>>> [] 0xffffffffffffffff >>>> >>>> Reported-by: Masami Ichikawa >>>> Signed-off-by: Kees Cook >>>> Cc: stable@vger.kernel.org >>> >>> Acked-by: Alexei Starovoitov >>> >>>> --- >>>> kernel/seccomp.c | 2 ++ >>>> 1 file changed, 2 insertions(+) >>>> >>>> diff --git a/kernel/seccomp.c b/kernel/seccomp.c >>>> index fd609bd9d6dd..2d7dcdfb7422 100644 >>>> --- a/kernel/seccomp.c >>>> +++ b/kernel/seccomp.c >>>> @@ -256,6 +256,7 @@ static long seccomp_attach_filter(struct sock_fprog *fprog) >>>> goto free_prog; >>>> >>>> /* Allocate a new seccomp_filter */ >>>> + ret = -ENOMEM; >>>> filter = kzalloc(sizeof(struct seccomp_filter) + >>>> sizeof(struct sock_filter_int) * new_len, >>>> GFP_KERNEL|__GFP_NOWARN); >>>> @@ -265,6 +266,7 @@ static long seccomp_attach_filter(struct sock_fprog *fprog) >>>> ret = sk_convert_filter(fp, fprog->len, filter->insnsi, &new_len); >>>> if (ret) >>>> goto free_filter; >>>> + kfree(fp); >>>> >>>> atomic_set(&filter->usage, 1); >>>> filter->len = new_len; >>>> -- >>>> 1.7.9.5 >>>> >>>> >>>> -- >>>> Kees Cook >>>> Chrome OS Security >> >> James (or anyone), can you be sure to pull this soon? I'd like to get >> it into 3.14 stable ASAP. Under kernel memory pressure, it would be >> possible for the prctl to return 0 without having attached the seccomp >> filter. > > I don't think it affects stable. > Fixes: bd4cf0ed331a ("net: filter: rework/optimize internal BPF > interpreter's instruction set") Oh! You're completely right. I've been running -next too long. :) Okay, no urgency at all and the Cc can be dropped. Whew! -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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/