From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f70.google.com (mail-wm0-f70.google.com [74.125.82.70]) by kanga.kvack.org (Postfix) with ESMTP id 654E46B0262 for ; Mon, 23 May 2016 08:07:05 -0400 (EDT) Received: by mail-wm0-f70.google.com with SMTP id f75so14826245wmf.2 for ; Mon, 23 May 2016 05:07:05 -0700 (PDT) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id v8si43777182wjf.38.2016.05.23.05.07.04 for (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 23 May 2016 05:07:04 -0700 (PDT) Subject: Re: bpf: use-after-free in array_map_alloc References: <5713C0AD.3020102@oracle.com> <20160417172943.GA83672@ast-mbp.thefacebook.com> <5742F127.6080000@suse.cz> From: Vlastimil Babka Message-ID: <5742F267.3000309@suse.cz> Date: Mon, 23 May 2016 14:07:03 +0200 MIME-Version: 1.0 In-Reply-To: <5742F127.6080000@suse.cz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Alexei Starovoitov , Sasha Levin Cc: ast@kernel.org, "netdev@vger.kernel.org" , LKML , Tejun Heo , Christoph Lameter , Linux-MM layout On 05/23/2016 02:01 PM, Vlastimil Babka wrote: >> if I read the report correctly it's not about bpf, but rather points to >> the issue inside percpu logic. >> First __alloc_percpu_gfp() is called, then the memory is freed with >> free_percpu() which triggers async pcpu_balance_work and then >> pcpu_extend_area_map is hitting use-after-free. >> I guess bpf percpu array map is stressing this logic the most. > > I've been staring at it for a while (not knowing the code at all) and > the first thing that struck me is that pcpu_extend_area_map() is done > outside of pcpu_lock. So what prevents the chunk from being freed during > the extend? Erm to be precise, pcpu_lock is unlocked just before calling pcpu_extend_area_map(), which relocks it after an allocation, and assumes the chunk still exists at that point. Unless I'm missing something, that's an unlocked window where chunk can be destroyed by the workfn, as the report suggests? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754431AbcEWMHI (ORCPT ); Mon, 23 May 2016 08:07:08 -0400 Received: from mx2.suse.de ([195.135.220.15]:59351 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752428AbcEWMHF (ORCPT ); Mon, 23 May 2016 08:07:05 -0400 Subject: Re: bpf: use-after-free in array_map_alloc To: Alexei Starovoitov , Sasha Levin References: <5713C0AD.3020102@oracle.com> <20160417172943.GA83672@ast-mbp.thefacebook.com> <5742F127.6080000@suse.cz> Cc: ast@kernel.org, "netdev@vger.kernel.org" , LKML , Tejun Heo , Christoph Lameter , Linux-MM layout From: Vlastimil Babka Message-ID: <5742F267.3000309@suse.cz> Date: Mon, 23 May 2016 14:07:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <5742F127.6080000@suse.cz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/23/2016 02:01 PM, Vlastimil Babka wrote: >> if I read the report correctly it's not about bpf, but rather points to >> the issue inside percpu logic. >> First __alloc_percpu_gfp() is called, then the memory is freed with >> free_percpu() which triggers async pcpu_balance_work and then >> pcpu_extend_area_map is hitting use-after-free. >> I guess bpf percpu array map is stressing this logic the most. > > I've been staring at it for a while (not knowing the code at all) and > the first thing that struck me is that pcpu_extend_area_map() is done > outside of pcpu_lock. So what prevents the chunk from being freed during > the extend? Erm to be precise, pcpu_lock is unlocked just before calling pcpu_extend_area_map(), which relocks it after an allocation, and assumes the chunk still exists at that point. Unless I'm missing something, that's an unlocked window where chunk can be destroyed by the workfn, as the report suggests?