Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp1254314pxa; Thu, 20 Aug 2020 06:52:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyDW3Fv7SSVyxFAXsx90HCVbHg6cToUvtoHhx8mkU+3KQpQUvSkiEAERJg75qapnfhJ6Oey X-Received: by 2002:a17:906:a182:: with SMTP id s2mr3244924ejy.526.1597931540228; Thu, 20 Aug 2020 06:52:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597931540; cv=none; d=google.com; s=arc-20160816; b=ODRJT68FgEo0bF/MndXjAbqdEMxHhGNh4mF26I70io2+p8AqxERhMARyuKvPjnNINS y2E1BMEc8A30fLECdUi59vOHmE7PsCvtIIPeDG/vm8mLHTdDRwFQ9/xUqBC6AlkZMbuN AVCHiEkA8HQB8TOJfSP+Y7qniXkr9hSbG8760TEfomU6rGa5PAifXGX0Cm3UuLTPpHgs vzCpYlLNpzZJEBWNWfU2rsId1PsLU4LKtp5F3Crqsiyx4CpxmfCWm4pM3Z2nanXa4u0e KnqExdYUHCuuWFZpY0/YgVlNSfGzxLAiOqegBGwDtOayDRA5WWSV2rqGfK6DuXCB3Xje neKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=e9GGBObctLxRMnUSxLBZMTy0/9BuKVFxN7TnUtjfrvU=; b=I3oEfCkZZx/fNP27VRHldwKOHP7uS0APrpmZkw13GuL9Oc+SmlnezNIxcRD0q8xzvU 4A4qdiO5XDqikvdgZqw3vWtL2bp3sJdS2Hb4daC3lAy8s/yWf18PRBAwFDzqA9airoyK nvOQYHUhojoYa6u8SObI4JwrtxGhqgq3/4oc9oejWSVLDrV3/yzZL3Nh8gZB0cY9zgQa EttepeDCjx4xbBAci3Gh1zp72mKlXCn+D0wlIuIxSUwElif4ff+pHIBPs3utroqJqS/z LUhTyLq1QcBB3lpa4vkPUgdcbK9y4CAXw9yb8nt0cnhds4c4W6olF5ItiayI5tgrmCgr O+lg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=ZzQx5UCm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z8si1216757ejj.334.2020.08.20.06.51.56; Thu, 20 Aug 2020 06:52:20 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=ZzQx5UCm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728923AbgHTNtd (ORCPT + 99 others); Thu, 20 Aug 2020 09:49:33 -0400 Received: from mail.kernel.org ([198.145.29.99]:37288 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726803AbgHTJ1k (ORCPT ); Thu, 20 Aug 2020 05:27:40 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CF84422CF7; Thu, 20 Aug 2020 09:27:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1597915659; bh=KxGgK/4VuD2mTN5Rtf1RJ71X4mSNQsxCLP9wnf98x84=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZzQx5UCm+gdc6ruooj+voDz8salZEcKmDV7H0eL/jctthMWFvPb8176qVknPG+03+ UHJC3ESLzxBxAN4MHcdjj7Aj586Tf8ENeKVrDLlgYFqUtwCJTLK/1sINkSkCCPHR0A 9g8Y7C9rsvXqLc2Q1RozPuzCUpw/UjmuMV2R64qs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Masami Hiramatsu , Muchun Song , Chengming Zhou , "Steven Rostedt (VMware)" Subject: [PATCH 5.8 089/232] kprobes: Fix NULL pointer dereference at kprobe_ftrace_handler Date: Thu, 20 Aug 2020 11:19:00 +0200 Message-Id: <20200820091617.143997246@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200820091612.692383444@linuxfoundation.org> References: <20200820091612.692383444@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Muchun Song commit 0cb2f1372baa60af8456388a574af6133edd7d80 upstream. We found a case of kernel panic on our server. The stack trace is as follows(omit some irrelevant information): BUG: kernel NULL pointer dereference, address: 0000000000000080 RIP: 0010:kprobe_ftrace_handler+0x5e/0xe0 RSP: 0018:ffffb512c6550998 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff8e9d16eea018 RCX: 0000000000000000 RDX: ffffffffbe1179c0 RSI: ffffffffc0535564 RDI: ffffffffc0534ec0 RBP: ffffffffc0534ec1 R08: ffff8e9d1bbb0f00 R09: 0000000000000004 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff8e9d1f797060 R14: 000000000000bacc R15: ffff8e9ce13eca00 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000080 CR3: 00000008453d0005 CR4: 00000000003606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ftrace_ops_assist_func+0x56/0xe0 ftrace_call+0x5/0x34 tcpa_statistic_send+0x5/0x130 [ttcp_engine] The tcpa_statistic_send is the function being kprobed. After analysis, the root cause is that the fourth parameter regs of kprobe_ftrace_handler is NULL. Why regs is NULL? We use the crash tool to analyze the kdump. crash> dis tcpa_statistic_send -r : callq 0xffffffffbd8018c0 The tcpa_statistic_send calls ftrace_caller instead of ftrace_regs_caller. So it is reasonable that the fourth parameter regs of kprobe_ftrace_handler is NULL. In theory, we should call the ftrace_regs_caller instead of the ftrace_caller. After in-depth analysis, we found a reproducible path. Writing a simple kernel module which starts a periodic timer. The timer's handler is named 'kprobe_test_timer_handler'. The module name is kprobe_test.ko. 1) insmod kprobe_test.ko 2) bpftrace -e 'kretprobe:kprobe_test_timer_handler {}' 3) echo 0 > /proc/sys/kernel/ftrace_enabled 4) rmmod kprobe_test 5) stop step 2) kprobe 6) insmod kprobe_test.ko 7) bpftrace -e 'kretprobe:kprobe_test_timer_handler {}' We mark the kprobe as GONE but not disarm the kprobe in the step 4). The step 5) also do not disarm the kprobe when unregister kprobe. So we do not remove the ip from the filter. In this case, when the module loads again in the step 6), we will replace the code to ftrace_caller via the ftrace_module_enable(). When we register kprobe again, we will not replace ftrace_caller to ftrace_regs_caller because the ftrace is disabled in the step 3). So the step 7) will trigger kernel panic. Fix this problem by disarming the kprobe when the module is going away. Link: https://lkml.kernel.org/r/20200728064536.24405-1-songmuchun@bytedance.com Cc: stable@vger.kernel.org Fixes: ae6aa16fdc16 ("kprobes: introduce ftrace based optimization") Acked-by: Masami Hiramatsu Signed-off-by: Muchun Song Co-developed-by: Chengming Zhou Signed-off-by: Chengming Zhou Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman --- kernel/kprobes.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -2113,6 +2113,13 @@ static void kill_kprobe(struct kprobe *p * the original probed function (which will be freed soon) any more. */ arch_remove_kprobe(p); + + /* + * The module is going away. We should disarm the kprobe which + * is using ftrace. + */ + if (kprobe_ftrace(p)) + disarm_kprobe_ftrace(p); } /* Disable one kprobe */