From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7A823CFC270 for ; Tue, 15 Oct 2024 06:42:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B73516B008C; Tue, 15 Oct 2024 02:42:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B231B6B0092; Tue, 15 Oct 2024 02:42:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9EA716B0093; Tue, 15 Oct 2024 02:42:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 805EF6B008C for ; Tue, 15 Oct 2024 02:42:43 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id ACAD381410 for ; Tue, 15 Oct 2024 06:42:35 +0000 (UTC) X-FDA: 82674893070.09.E28549A Received: from pegase2.c-s.fr (pegase2.c-s.fr [93.17.235.10]) by imf24.hostedemail.com (Postfix) with ESMTP id CA0F2180009 for ; Tue, 15 Oct 2024 06:42:38 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=csgroup.eu; spf=pass (imf24.hostedemail.com: domain of christophe.leroy@csgroup.eu designates 93.17.235.10 as permitted sender) smtp.mailfrom=christophe.leroy@csgroup.eu ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728974529; a=rsa-sha256; cv=none; b=gSKG0Bzlj1h5ICqH2Xw5rFFpLxqNIstdqQ5QZb3cxcffZmMkpCKuzEIpv7b0a8VV4mMNtE r5Fcd11oNIsZQlENi8qa785XDADC+U5smvEzSEf3sobEmZM40NGlo/fK5trHGRBoLoDI2W 2XOOkCNBrazxsZ1ssFDLhLKM90Bs+pk= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=csgroup.eu; spf=pass (imf24.hostedemail.com: domain of christophe.leroy@csgroup.eu designates 93.17.235.10 as permitted sender) smtp.mailfrom=christophe.leroy@csgroup.eu ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728974529; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yZY8Q+WVwnCzpj20CVghuUX3o6Hwo32dGoF20noZK+8=; b=6RFP8Xi4W5JMKKCNtYda9YPlJ5z7MeM/r88ug4NKTdp1Udk1VA7OwSCKjFnyaGJ7gfJ5Hg HXukS3SiNcIAHpfBlf8rpxwykoCrvskQqI18EoLFBOSoFMWcyCkyPvKc+6n4wfxQE4HvHh uwTMh546YBmv3Tx2FQqTZ+hs4cFLBnc= Received: from localhost (mailhub3.si.c-s.fr [172.26.127.67]) by localhost (Postfix) with ESMTP id 4XSPfk3bvFz9sPd; Tue, 15 Oct 2024 08:42:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at c-s.fr Received: from pegase2.c-s.fr ([172.26.127.65]) by localhost (pegase2.c-s.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWUMtT-TFO-Y; Tue, 15 Oct 2024 08:42:38 +0200 (CEST) Received: from messagerie.si.c-s.fr (messagerie.si.c-s.fr [192.168.25.192]) by pegase2.c-s.fr (Postfix) with ESMTP id 4XSPfk2bjlz9rvV; Tue, 15 Oct 2024 08:42:38 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 456068B766; Tue, 15 Oct 2024 08:42:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at c-s.fr Received: from messagerie.si.c-s.fr ([127.0.0.1]) by localhost (messagerie.si.c-s.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id haU307l0a_y8; Tue, 15 Oct 2024 08:42:38 +0200 (CEST) Received: from [192.168.233.13] (unknown [192.168.233.13]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 6D1568B764; Tue, 15 Oct 2024 08:42:37 +0200 (CEST) Message-ID: <660a2cf7-24f9-4558-87df-5e4c13362380@csgroup.eu> Date: Tue, 15 Oct 2024 08:42:36 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC RESEND v2 02/13] powerpc: mm: Fix kfence page fault reporting To: "Ritesh Harjani (IBM)" , linuxppc-dev@lists.ozlabs.org Cc: kasan-dev@googlegroups.com, linux-mm@kvack.org, Marco Elver , Alexander Potapenko , Heiko Carstens , Michael Ellerman , Nicholas Piggin , Madhavan Srinivasan , Hari Bathini , "Aneesh Kumar K . V" , Donet Tom , Pavithra Prakash , LKML , Disha Goel References: <6bf523aa03e72d701d24aca49b51864331eed2d5.1728954719.git.ritesh.list@gmail.com> Content-Language: fr-FR From: Christophe Leroy In-Reply-To: <6bf523aa03e72d701d24aca49b51864331eed2d5.1728954719.git.ritesh.list@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspam-User: X-Stat-Signature: ndfng7bcr96dz9tj64tqhg4ato8t95j4 X-Rspamd-Queue-Id: CA0F2180009 X-Rspamd-Server: rspam02 X-HE-Tag: 1728974558-416404 X-HE-Meta: U2FsdGVkX1/tVwjcaqmVry/hYEWgK07nhcTWoWvkCQaVCbu0MDdTutT+Sxx6Cz9krZruT9gbYmYHyYUVoeBZgRgKO96ilge7ilCslpXh96A/+izbZUq6UWoDfcuReYYKIFJLQjxczyrtsncH69+5tDM6l0r1J53ZTJSeUIocMewy0+CPuaBuhF7T6WQU5TJYP8cqnBMprtvgajeUI8xdxCKSKp2VWiXIHAOEuCBGOM07+GFlNL7jWpH3J1MursLJYzFmblGAemJTudpC+AUpK6higy4V2x4AwrAimF8nVmITkW1FF4rtDX7rHG+4HTvr/Ca+aCF2pUPkrdXfsAdBzx19m6lb1/ZSleFluuJpbbWQuuBV9sozE0+JFBZJCpt8OBaYu5huCQ5fgWIACQCo7a9xTp/3DbkJR/x2WBgbRRB86+RSoUTurhJd1XqjozPAxD7GLlCzcPk8+Rx6mV1UkIXTPEsIhkb9wiN71TVp7niWFw66xH6VMynjo6CT+7Vfv9iBNzDbmUZYfDi0QyxlmxF4/MqUAJbbcg2XBs3XDLI174LUXTVWoTlFeOWid32MOe36WVztIFWrsC51e6Pbg61KpsaRA6cNJ1R3kGmk7YR5bTDjNUNGZFKGVnAH1UQsg6Tx1cckvcOL2NHMYK0xLdqCUNHnTn3fBOCe9oTeB97YOFTqIQJ9t8Vv5tAwhEgv+vSTl96LJHrkqgFJwLEksdku/d9I5i8jHhiWJUDCKMd8xK48Ks7Dh3tnjA/NcIcLdW0K2+Gkn7akpI01hAO0X26jgyj0VwWfbBu7R5F3XcNi5onFhC9iq7cfxGgZ12C2pNTCC59M42EnFjE4ynl13gUS1xpkEzHT0mp1gBs2cWmLBT3JSG5XUYW4eNkSsQBspJeVEMRFnvl7KwA1zFoTS2CmqUqD/8EH3ouhS0jvwby4Ip7Tv6x/4VMTnlzz0iTt1c9kJsl6TaZMPl693QZ h1Jada17 xkJEi1sDh1Tw9vwbpbekDiKcL94gwD1JFppv3azqsa3qJiEcDmus68Vx+Fp11tJ04S0d0mofh7AJMZ6aMmQ54f/gRATFCg5yc985IuRxtz+Npkw5/oQm10Wavj2//MUjbaQOyttMpf4WfEOQvqc9BaCwEJrMzlgcW6Loxkr++vATT13MH15HCfWf9AqCKstPN6kgIduTal+E+DwJQShcbQGN+99aaxstAQcYcUoNRSJWRICWtS5fIYJNsWVQ5eGi608t9 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Le 15/10/2024 à 03:33, Ritesh Harjani (IBM) a écrit : > copy_from_kernel_nofault() can be called when doing read of /proc/kcore. > /proc/kcore can have some unmapped kfence objects which when read via > copy_from_kernel_nofault() can cause page faults. Since *_nofault() > functions define their own fixup table for handling fault, use that > instead of asking kfence to handle such faults. > > Hence we search the exception tables for the nip which generated the > fault. If there is an entry then we let the fixup table handler handle the > page fault by returning an error from within ___do_page_fault(). > > This can be easily triggered if someone tries to do dd from /proc/kcore. > dd if=/proc/kcore of=/dev/null bs=1M > > > =============================== > BUG: KFENCE: invalid read in copy_from_kernel_nofault+0xb0/0x1c8 > Invalid read at 0x000000004f749d2e: > copy_from_kernel_nofault+0xb0/0x1c8 > 0xc0000000057f7950 > read_kcore_iter+0x41c/0x9ac > proc_reg_read_iter+0xe4/0x16c > vfs_read+0x2e4/0x3b0 > ksys_read+0x88/0x154 > system_call_exception+0x124/0x340 > system_call_common+0x160/0x2c4 > > BUG: KFENCE: use-after-free read in copy_from_kernel_nofault+0xb0/0x1c8 > Use-after-free read at 0x000000008fbb08ad (in kfence-#0): > copy_from_kernel_nofault+0xb0/0x1c8 > 0xc0000000057f7950 > read_kcore_iter+0x41c/0x9ac > proc_reg_read_iter+0xe4/0x16c > vfs_read+0x2e4/0x3b0 > ksys_read+0x88/0x154 > system_call_exception+0x124/0x340 > system_call_common+0x160/0x2c4 > > Guessing the fix should go back to when we first got kfence on PPC32. > > Fixes: 90cbac0e995d ("powerpc: Enable KFENCE for PPC32") > Reported-by: Disha Goel > Signed-off-by: Ritesh Harjani (IBM) > --- > arch/powerpc/mm/fault.c | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c > index 81c77ddce2e3..fa825198f29f 100644 > --- a/arch/powerpc/mm/fault.c > +++ b/arch/powerpc/mm/fault.c > @@ -439,9 +439,17 @@ static int ___do_page_fault(struct pt_regs *regs, unsigned long address, > /* > * The kernel should never take an execute fault nor should it > * take a page fault to a kernel address or a page fault to a user > - * address outside of dedicated places > + * address outside of dedicated places. > + * > + * Rather than kfence reporting false negatives, let the fixup table > + * handler handle the page fault by returning SIGSEGV, if the fault > + * has come from functions like copy_from_kernel_nofault(). > */ > if (unlikely(!is_user && bad_kernel_fault(regs, error_code, address, is_write))) { > + > + if (search_exception_tables(instruction_pointer(regs))) > + return SIGSEGV; This is a heavy operation. It should at least be done only when KFENCE is built-in. kfence_handle_page_fault() bails out immediately when is_kfence_address() returns false, and is_kfence_address() returns always false when KFENCE is not built-in. So you could check that before calling the heavy weight search_exception_tables(). if (is_kfence_address(address) && !search_exception_tables(instruction_pointer(regs)) && kfence_handle_page_fault(address, is_write, regs)) return 0; > + return SIGSEGV; > + > if (kfence_handle_page_fault(address, is_write, regs)) > return 0; >