From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm2-f0.google.com (mail-wm2-f0.google.com [74.125.225.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 051753B8D50 for ; Wed, 8 Jul 2026 05:38:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.225.128 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783489128; cv=none; b=XTLUHNOVe9BOVyZXsi2XWuTXQTvZGv+zr5ND+8jHdkSCJoLOZ9T1DoY8SFe/D8bWpJ1LlnYoy4io+AL80uHA4X2CdVwraCIUQX1yv/RidXV4WqAhnD8sRQHDQjGG0cqAC6wk9tiXgX0PssdzKT6zcU1d774wd7Tl3zQL/9do0NU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783489128; c=relaxed/simple; bh=M7EasDgFdwe2wKlA/Xcb/xGQY9xr1kDs5eTf9YwG4t4=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=KqeHRpO8pLMm3mqPzKKX+WWj9KumOeLl0FR7+A5XtyqZrXkwQKr3k/CYEIPOYmaOdpdf7ttkZnKw2P7ieT0+qrmfV1e6Q9K2Sz1FaKRofSBylNNCrRdRjgAqGa1OQ6Ge/oZiYGXNh1Py/Pp6e8DLmunNtD4tE43WBZ7F10yP0cQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=dNFTbneG; arc=none smtp.client-ip=74.125.225.128 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="dNFTbneG" Received: by mail-wm2-f0.google.com with SMTP id 5b1f17b1804b1-493b4af7976so1575055e9.1 for ; Tue, 07 Jul 2026 22:38:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783489125; x=1784093925; darn=vger.kernel.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=YTTheAhlIxpIbm6yj8zsEe6uPaF2F+fnjj/Td1Qqkgk=; b=dNFTbneGBmovmKEqiAquVFyhOhrmrd8YK8zqwds1Sx460ZEr7dGoGHMnDz44Lv9ZBP dtefJx9QSpOtM0NcJcrXY6K3eQWDLcN4MvI1NKWet2KBNyTlHW9y9RTQCFaMErwTMOOk Zk4/nnNHcxXTp3P5S3y0T0GFm1x7iv7zSXYcGw0fy6bh9KL98ZEEvN3lwarGiekVWhzF eflVkwE1HXjIpf2zIHzCGiRAsrGjmLKQKQhCu6lBlBRCsp7Rf2by44Zv99kcbyJyJqhI T0poeJ6nj1Cgv48xi2hwwTgLXENtLM/SfTP7JjjosyYqF44P6dEwkNX43r6Im3IGvz8e 9msw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783489125; x=1784093925; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=YTTheAhlIxpIbm6yj8zsEe6uPaF2F+fnjj/Td1Qqkgk=; b=disCyu3eGZsSK6/Ag0nAPSRG/VzEs10rhRe7aMS15FV86TmCPjpevLDD3XXDjIjbfs nfLA6JkiBCemb8zs3e8OsDGv7yN0X46djxEcORNNQCzmPzpY2r5JS7xDEhkXXjqEfNrm HmTKVqhxUSPqEIWP63E5/T7+hd/coIojFY5xllhk4X2KAsU7kGvXqi68kwqfdJx6/Ci9 WzY+mw8DTKv+Dk2IJewGKTsDRjeHujoW+1AGIkP+o3RZbChsl1ajyxP5bXBxg4ngUfdl ekhB5QV/jpTPoCzIkuYikMU341akuG35dai5P+MuylnJqvcCdCsoGkjOPp7YQvw0Lnpb ZfDA== X-Forwarded-Encrypted: i=1; AHgh+Rqb3di7u21UGbV+vb+E+cdkGpEtfoemmitPaZUWDkqEFwzkES5a5yvZ0uhU8AUPNXuNF5aLMuvJH/0nftk=@vger.kernel.org X-Gm-Message-State: AOJu0YyCJDP0V1ix8wuLJIpryyzBNwnOA2wtlOO4w12lhdBw4vv13YCc lF1z0PtZ7AKuiU9/xfZ3iOHaL+Dz2zVawPmZGtM681MExVYrI41mzFWs X-Gm-Gg: AfdE7clVGVC+a+bK+O7JrymKSth2i7Q9PlDdNubDxiCCxOrhLU9NfIel37Ud71ZplhY LogX7HuZ6xPGoynoHcjimzGeN5cUmYwyFqi6NrtBcgBVA4CUjHPZQ6wIJ/sGFK1ZWiNWttg+9Ue rPg5VlWdlBtifC0vGsO3ClvFNXOrHxpx1jSCXuQ8NN0dsoey+tdS6ov9Z9AE9Cv6y52Cn+THf9G om4+71U0ax9hzdM/LRQCix/xnj1s8MhSrB3EKwnUErYaq9lbByB2ewiUXD1dMjZwawcCNJpRzxV yLUKkTUFlgA0WJ+v7n46PCdkN3BD4PDddf/qC+aPRn/yF/lZXLvLqFWch5irjWCfNbMmr9+eSCp h3CM6lu1/r7IIosJi7HBj1QhGR8aUd3kF+FvZGCAHziVj/ZE/2+8Zv0Hrjka0bDGi3Gu1Z6W7UC fZ5iUz60SZbUVnbgaDqlkT5/6gZ+Ygt0oLBdPWNNAghmVZwG38gcMrIZaW+UWFRohjN7hmNAYe1 QblXrK/E61+ikWcSPNp/Yf1FrjrF1L1rxqkAJ62LAekav3Jlb/OavE= X-Received: by 2002:a05:6000:18a9:b0:475:f0f0:9f00 with SMTP id ffacd0b85a97d-47df0788276mr718549f8f.55.1783489125113; Tue, 07 Jul 2026 22:38:45 -0700 (PDT) Received: from localhost (nat-icclus-192-26-29-3.epfl.ch. [192.26.29.3]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47aa039ae44sm38187651f8f.23.2026.07.07.22.38.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jul 2026 22:38:44 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 08 Jul 2026 07:38:44 +0200 Message-Id: Cc: "Puranjay Mohan" , "Andrii Nakryiko" , "Yonghong Song" , "Alexei Starovoitov" , "Andrii Nakryiko" , "Martin KaFai Lau" , "Eduard Zingerman" , "Song Liu" , "Kumar Kartikeya Dwivedi" , "John Fastabend" , "KP Singh" , "Stanislav Fomichev" , "Hao Luo" , "Jiri Olsa" , "Emil Tsalapatis" , , Subject: Re: [PATCH bpf-next v6] bpf: Fix use-after-free on mm_struct in bpf_find_vma() From: "Kumar Kartikeya Dwivedi" To: "Sanghyun Park" , "Daniel Borkmann" X-Mailer: aerc 0.21.0 References: <20260630032543.3165720-1-sanghyun.park.cnu@gmail.com> <4d09e590-9b03-4025-b334-ea2351770b57@iogearbox.net> In-Reply-To: On Wed Jul 8, 2026 at 7:28 AM CEST, Sanghyun Park wrote: > Sure, > Please avoid top-posting. > I=E2=80=99ll take a look at that issue once the current patch is sorted o= ut. > We had to drop this from the tree because of build-time warnings [0], since mmput_needed will not be used in case CONFIG_MMU is unset. It should be eas= y to address by adding __maybe_unused to the mmput_needed's declaration. Coul= d you make that fix and respin? [0]: https://lore.kernel.org/bpf/202607080951.rMUtVX8X-lkp@intel.com > 2026=EB=85=84 7=EC=9B=94 7=EC=9D=BC (=ED=99=94) =EC=98=A4=ED=9B=84 4:44, = Daniel Borkmann =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1= : >> >> On 7/6/26 1:28 PM, Puranjay Mohan wrote: >> > On Wed, Jul 1, 2026 at 8:48=E2=80=AFPM Andrii Nakryiko >> > wrote: >> >> >> >> On Mon, Jun 29, 2026 at 8:25=E2=80=AFPM Sanghyun Park >> >> wrote: >> >>> >> >>> bpf_find_vma() reads task->mm and calls mmap_read_trylock(mm) withou= t >> >>> holding a reference on the mm. On a foreign task, a concurrent exit_= mm() >> >>> can free the mm_struct between the lockless read and the trylock, >> >>> resulting in a use-after-free. mm_struct is not SLAB_TYPESAFE_BY_RCU= . >> >>> >> >>> For the current task, task->mm is stable. For a foreign task, pin th= e mm >> >>> under task->alloc_lock and release it with mmput_async(), mirroring = commit >> >>> d8e27d2d22b6 ("bpf: fix mm lifecycle in open-coded task_vma iterator= "). >> >>> Use spin_trylock() instead of get_task_mm() so BPF context does not = block >> >>> on alloc_lock. Reject irqs-disabled contexts and !CONFIG_MMU on the >> >>> foreign-task path because dropping the mm reference is not safe ther= e. >> >>> >> >>> Race: >> >>> >> >>> CPU0 (BPF program) CPU1 (exiting task) >> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >>> bpf_find_vma(foreign_task): >> >>> mm =3D task->mm >> >>> exit_mm(): >> >>> task->mm =3D NULL >> >>> mmput(mm) -> frees mm_struc= t >> >>> mmap_read_trylock(mm) >> >>> // UAF on mm >> >>> >> >>> Fixes: 7c7e3d31e785 ("bpf: Introduce helper bpf_find_vma") >> >>> Acked-by: Yonghong Song >> >>> Signed-off-by: Sanghyun Park >> >>> --- >> >> >> >> Puranjay, PTAL, I think you've been fixing similar issue in >> >> bpf_iter_task_vma_new(), would be nice for you to check this fix as >> >> well. Thanks! >> >> >> >>> v6: >> >>> - Restore bpf_iter_mmput_async() because bpf_iter_task_vma_destroy= () >> >>> still uses it. >> >>> - Keep the direct mmput_async() call in bpf_find_vma(), but guard = it with >> >>> CONFIG_MMU because mmput_async() is declared only for CONFIG_MMU= builds. >> >>> v5: https://lore.kernel.org/bpf/20260630023443.3026627-2-sanghyun.pa= rk.cnu@gmail.com/ >> >>> - Replace bpf_iter_mmput_async() with mmput_async() directly as su= ggested >> >>> by Yonghong. >> >>> - Add Yonghong's Acked-by. >> >>> v4: https://lore.kernel.org/bpf/20260610024637.343364-1-sanghyun.par= k.cnu@gmail.com/ >> >>> - Use [PATCH bpf-next] subject as requested by Alexei. >> >>> - Add the missing BPF maintainers/reviewers to Cc. >> >>> v3: https://lore.kernel.org/bpf/20260609105216.3536839-1-sanghyun.pa= rk.cnu@gmail.com/ >> >>> - Drop get_task_mm()+mmput(); mirror d8e27d2d22b6 with alloc_lock >> >>> trylock + mmput_async(). (Yonghong Song) >> >>> - Reject irqs-disabled contexts on the foreign-task path. >> >>> - Reject foreign-task path when !CONFIG_MMU: bpf_iter_mmput_async(= ) >> >>> falls back to mmput() which may sleep, and bpf_find_vma() can ru= n >> >>> in non-sleepable context. >> >>> - Shorten the foreign-task rationale comment and trim the changelo= g body. >> >>> - Fix the v2's whitespace damage. >> >>> v2: https://lore.kernel.org/bpf/CAOrxSK5_7e4114VyfEU9htGi+UneuNt88fG= VKOAa3_ZenPOFkA@mail.gmail.com/ >> >>> >> >>> kernel/bpf/task_iter.c | 36 +++++++++++++++++++++++++++++++++--- >> >>> 1 file changed, 33 insertions(+), 3 deletions(-) >> >>> >> >>> diff --git a/kernel/bpf/task_iter.c b/kernel/bpf/task_iter.c >> >>> index fc5f463ca529a..1d56193caf5e4 100644 >> >>> --- a/kernel/bpf/task_iter.c >> >>> +++ b/kernel/bpf/task_iter.c >> >>> @@ -760,6 +760,7 @@ BPF_CALL_5(bpf_find_vma, struct task_struct *, t= ask, u64, start, >> >>> struct mmap_unlock_irq_work *work =3D NULL; >> >>> struct vm_area_struct *vma; >> >>> bool irq_work_busy =3D false; >> >>> + bool mmput_needed =3D false; >> >>> struct mm_struct *mm; >> >>> int ret =3D -ENOENT; >> >>> >> >>> @@ -769,14 +770,38 @@ BPF_CALL_5(bpf_find_vma, struct task_struct *,= task, u64, start, >> >>> if (!task) >> >>> return -ENOENT; >> >>> >> >>> - mm =3D task->mm; >> >>> + if (task =3D=3D current) { >> >>> + mm =3D task->mm; >> >>> + } else { >> >>> + /* >> >>> + * Foreign task: pin task->mm against a concurrent e= xit_mm(). >> >>> + * Use trylock on alloc_lock instead of get_task_mm(= )'s >> >>> + * blocking task_lock() to avoid deadlocking the tar= get task. >> >>> + */ >> >>> + if (!IS_ENABLED(CONFIG_MMU)) >> >>> + return -EOPNOTSUPP; >> >>> + if (irqs_disabled()) >> >>> + return -EBUSY; >> >>> + if (!spin_trylock(&task->alloc_lock)) >> >>> + return -EBUSY; >> >>> + mm =3D task->mm; >> >>> + if (mm && !(task->flags & PF_KTHREAD)) { >> >>> + mmget(mm); >> >>> + mmput_needed =3D true; >> >>> + } else { >> >>> + mm =3D NULL; >> >>> + } >> >>> + spin_unlock(&task->alloc_lock); >> >>> + } >> >>> if (!mm) >> >>> return -ENOENT; >> >>> >> >>> irq_work_busy =3D bpf_mmap_unlock_get_irq_work(&work); >> >>> >> >>> - if (irq_work_busy || !mmap_read_trylock(mm)) >> >>> - return -EBUSY; >> >>> + if (irq_work_busy || !mmap_read_trylock(mm)) { >> >>> + ret =3D -EBUSY; >> >>> + goto out; >> >>> + } >> >>> >> >>> vma =3D find_vma(mm, start); >> >>> >> >>> @@ -786,6 +811,11 @@ BPF_CALL_5(bpf_find_vma, struct task_struct *, = task, u64, start, >> >>> ret =3D 0; >> >>> } >> >>> bpf_mmap_unlock_mm(work, mm); >> >>> +out: >> >>> +#ifdef CONFIG_MMU >> >>> + if (mmput_needed) >> >>> + mmput_async(mm); >> >>> +#endif >> >>> return ret; >> >>> } >> >>> >> >>> -- >> >>> 2.48.1 >> > >> > Thanks for this, it looks good to me. >> > >> > Reviewed-by: Puranjay Mohan >> >> Applied, thanks! Could either you or Sanghyun look into the pre-existing >> sashiko-reported issue as well?