Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp439520ybh; Sat, 7 Mar 2020 01:56:49 -0800 (PST) X-Google-Smtp-Source: ADFU+vtcmILExN9TJ0D9V5Z6lupLGcUyEvkRChosNTXzo5qQYXpaANboET4VdvPgPRiyq4eUZ7zw X-Received: by 2002:a9d:907:: with SMTP id 7mr1760404otp.278.1583575009479; Sat, 07 Mar 2020 01:56:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583575009; cv=none; d=google.com; s=arc-20160816; b=kgMJGq7DHCz+KiV2FCB8aRGpu8WhjHT7Qgr+dlUEU8aE/6OOrh3y0kW2dcNV2CioL8 txojb3EVjPA8O/PYBn/Rbc/3MknEq0W8yd3qKFyLGxhuAP1XnC+a+hZmKWgVO2O2bMyO 2bBjF+MtT2zyE29eePiA0T9QbbY7p2OVyubRCb8EQYfqj6z/HAHGxQma/4M8M+Atc0v5 IwxayLi4sXaCahPu5CgrR1GWnKgXvdVAwVcB0kR8AkQbbHJ73M8gVM+tZDGqppEyRqwb zzipcy67OiwLgi5F4MYnlkNRvh61WHyIkyIA0gBnTbwM0lTZ94pzRp5OZUvmDL7b7UwC ff7w== 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 :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=o/rXDOSc2sPRD74Oy723iwugiVU8075MZRSwBAO8UOw=; b=CXceKdHvF02nXUSUHyOLxlSJbwqdtJShEOtCuZHTbJHzLChl4tef0rLRxpkJzZlFIS kMowIybH0HUmrbLx/p5m9NNQPkXzEb87QSk8zTJkvE4j+rpAomrlfChWonYZQzq4+qZR DHobqOEFE6uqBuwMenOEYWfZTzKmABDrNAGl/cNk20+bFI4q3NmYAICSkhANzs20Ky7d C9d7M6gnCDCsB9QmdS798WXvWbpBwSKqzIp4CAaB8+fueiKGFKeXxlOg1qCEgOjsznq0 tyiiehJ+WQNIVDLlZdhX4SWsr82rl+C/NMBEwIgtpewfH8G6OwZRE+b5sbcYk6TpSqyx SEWw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="U49/ZN5x"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k17si667984oij.141.2020.03.07.01.56.37; Sat, 07 Mar 2020 01:56:49 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="U49/ZN5x"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726225AbgCGJyp (ORCPT + 99 others); Sat, 7 Mar 2020 04:54:45 -0500 Received: from mail.kernel.org ([198.145.29.99]:55304 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726072AbgCGJyo (ORCPT ); Sat, 7 Mar 2020 04:54:44 -0500 Received: from devnote2 (NE2965lan1.rev.em-net.ne.jp [210.141.244.193]) (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 1DDBC2073D; Sat, 7 Mar 2020 09:54:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1583574884; bh=gQRp4hFTqo4KkDpvhpmcHmhosoj3bEke3t7VFR4Ae1w=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=U49/ZN5xSCyzsM/kraUH/xSsLapsiK4cis7pIBjBD0nMOJoWNVhakn2slJnjrZs7A pX6CmHD9zoNFF0XLdZ55qFgfjLjWq8Z7V7gFOzxKYphWjMXElOTM2P5h+2koWGd+Pc arFIlMBCwThbkHb3pWO+EKAL/P+mPE7J9tVAWzeI= Date: Sat, 7 Mar 2020 18:54:39 +0900 From: Masami Hiramatsu To: "chengjian (D)" Cc: Ingo Molnar , , , , , , , Subject: Re: [PATCH] kretprobe: check re-registration of the same kretprobe earlier Message-Id: <20200307185439.9e88f3c8b55a3f11923ea694@kernel.org> In-Reply-To: <9b122a6f-f5fa-3eb4-4fd7-f101b8aec205@huawei.com> References: <1583487306-81985-1-git-send-email-cj.chengjian@huawei.com> <20200307002115.b96be2310cc553a922e1ba31@kernel.org> <9b122a6f-f5fa-3eb4-4fd7-f101b8aec205@huawei.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.32; x86_64-pc-linux-gnu) 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 On Sat, 7 Mar 2020 10:16:35 +0800 "chengjian (D)" wrote: > > On 2020/3/6 23:21, Masami Hiramatsu wrote: > > Hi Cheng, > > > > On Fri, 6 Mar 2020 17:35:06 +0800 > > Cheng Jian wrote: > > > >> Our system encountered a use-after-free when re-register a > >> same kretprobe. it access the hlist node in rp->free_instances > >> which has been released already. > >> > >> Prevent re-registration has been implemented for kprobe before, > >> but it's too late for kretprobe. We must check the re-registration > >> before re-initializing the kretprobe, otherwise it will destroy the > >> data and struct of the kretprobe registered, it can lead to memory > >> leak and use-after-free. > > I couldn't get how it cause use-after-free, but it causes memory leak. > > Anyway, if we can help to find a wrong usage, it might be good. > > > > Acked-by: Masami Hiramatsu > > > > BTW, I think we should use WARN_ON() for this error, because this > > means the caller is completely buggy. > > > > Thank you, > > Hi Masami > > When we try to re-register the same kretprobe, the register_kprobe() > return failed and try to free_rp_inst > >     register_kretprobe() > >         raw_spin_lock_init(&rp->lock); >         INIT_HLIST_HEAD(&rp->free_instances);    # re-init > >         inst = kmalloc(sizeof(struct kretprobe_instance) + > p->data_size, GFP_KERNEL); # re-alloc > >         ret = register_kprobe(&rp->kp);  # failed > >         free_rp_inst(rp);   # free all the free_instances > > at the same time, the kretprobe registed handle(trigger), it tries to > access the free_instances. > > Since we broke the rp->lock and free_instances when re-registering, we > are accessing the newly > > allocated free_instances and it's being released. > > pre_handler_kretprobe > >     ri = hlist_entry(rp->free_instances.first, struct > kretprobe_instance, hlist); # access the new free_instances. BOOM!!! > >     hlist_del(&ri->hlist); #BOOM!!! Ah, I see. I thought that you said ri is use-after-free, but in reality, rp is use-after-free (use-after-init). OK. > And the problem here is destructive, it destroyed all the data of the > previously registered kretprobe, > it can lead to a system crash, memory leak, use-after-free and even some > other unexpected behavior. Yes, so I think we should do + /* Return error if it's being re-registered */ + ret = check_kprobe_rereg(&rp->kp); + if (WARN_ON(ret)) + return ret; This will give a warning message to the developer. Thank you, -- Masami Hiramatsu