Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp503880iog; Fri, 17 Jun 2022 07:42:46 -0700 (PDT) X-Google-Smtp-Source: AGRyM1uivkX+39zUjBx8d5HFMJ3Ocdr70xniDfVAo5iIPH/dBAHdz5FPhh0m63G1cXUh+oTNE3gy X-Received: by 2002:a17:906:1cc3:b0:711:24e4:70e1 with SMTP id i3-20020a1709061cc300b0071124e470e1mr9486292ejh.551.1655476966208; Fri, 17 Jun 2022 07:42:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655476966; cv=none; d=google.com; s=arc-20160816; b=cWtQq+Sc1MYb6zSJQADeeX9Dw+652a9JOJ4B+TCvwAdQrSLKm16bXey8njkCiuUBgX IcEEHqWB6cxkofxRlXymuxMJt9alkML6YwUgBHh3oiQSwYojMo0LbWhc8/0YAPDf6kIf r1tyjWQoHQ6v9K9utrb8gAp2wzZgPwUeXA2CPPw45rZ/fA2vs0vp+XSx31k0vcJN7ApD D8GJiBFevLktBLZVQxfU3ish7vcLyih+7mEDDvaZkt3Q7rkxYq96hEfXAPqK7cI1Ib21 Hk0oZya7n+pWKG+Z9PHUJBKAb/5s37UR7/pDEqENMofBEUE4tesuBD6FvngpsqTSJP3j GSog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:subject:cc:to:from :dkim-signature; bh=+N/16cyFHOuLupQ+Fk4F91U88SFBJPVf6lD4I/mDTOc=; b=qv08otVRrcU270ekTk9KBgd9YXXIUR/Sbm16hUIKGj6mVIx/XWKwpI5qnR403Nyo9n XAc/iz1CllFEhtuZfpNw6zijU12HPXOTfBIjNm9Y26C24O58xmsu20fIOJeGho3Nk6H/ d43bYg/0EJgcHUCLPWR+ZJsz35XoA00I0diEEfTKmvAEsmFmh5KS29aJCNsFhMc/M4oO OIVvfLT1VhQLWhUxcNgFpm/IUYKx40C2ZIh6NlJU3uMUX0W5S64P84Y/3j95ExdllCw1 lQvI7aF8tTyq5RotQpg1b2nCG8NGTWAPigLrnEBWujrJhlGIsch6jVx+cL8hUc201ZDX hSYQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=V5KGDpPp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s10-20020a056402520a00b0042dc3ae3acfsi3471543edd.140.2022.06.17.07.42.13; Fri, 17 Jun 2022 07:42:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=V5KGDpPp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1382517AbiFQOc7 (ORCPT + 99 others); Fri, 17 Jun 2022 10:32:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38580 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231490AbiFQOc4 (ORCPT ); Fri, 17 Jun 2022 10:32:56 -0400 Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 45779BCBC for ; Fri, 17 Jun 2022 07:32:55 -0700 (PDT) Received: by mail-pl1-x634.google.com with SMTP id a17so2068613pls.6 for ; Fri, 17 Jun 2022 07:32:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id; bh=+N/16cyFHOuLupQ+Fk4F91U88SFBJPVf6lD4I/mDTOc=; b=V5KGDpPpLv4gKA2kex+nq5K86WkTiTIUPC09l4jO/cjP1ray0Y9Tr7B2ih/Eu/jpl2 LKuWx2XSlpztoIENI4/C9THP2gsEW8QKc3JDClcSL/kL4btjUNvOJBL9iAzeWXthdNLH cDDhrJUtqfywTBaes+SYgeEm8et/TBg6dn1IccAZamdHRbyf4EnaChpBhwd3cBYR/uCm dR0Mxuw7PIDS6k67D2uB0ScaaeDaZbRLh4a/CyRUvWy7TFCQLfUJrop1w9uI4H7/SMqR /my/yQqVMu8QP2BWtGPmbAYUZIXyikuU3+Wi4Pr8too0nEhEWfoMlEH9Xhnu4QFzDXib alrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=+N/16cyFHOuLupQ+Fk4F91U88SFBJPVf6lD4I/mDTOc=; b=RZuX4aKKGdlGeMiMfOaGU4zQnK71PDasMTjM63K+4MqTmFpWjMeeebLwVSGGUcvg6W NCKtq7V1OlK8sB0x175DTnQdjPtAZRCR+599cZMpw8v+Wln9s+ksQTojUlrfGDT3G89E b5XR9L5nRaMRwL6tbfU7UGO/j+u/6Q/op3oSYj2xmfL/Tu7upKfM01Uq40RIQ+lzKMD2 t3Xl+oMiseXt0d5pXBpF+wp0I8M+bb+IaQrUT/a0Hn00D0mAYMLxiy2OdN2RibPkChqU yVCkGTgQa6lvfbfVXImAsjh3Rv+j/ZTBBcDqTr8566i668yoQ+4kcYFV2bIQM8R3tUgL UppQ== X-Gm-Message-State: AJIora8SGNGTuEUljH6DlyzDpvjIGcWnmjS5Oz/kS5oWZJusLwC7oFYq Z5JXOAGFW5SbNVYzXno38BE= X-Received: by 2002:a17:902:d502:b0:168:faa0:50a0 with SMTP id b2-20020a170902d50200b00168faa050a0mr9964651plg.142.1655476374750; Fri, 17 Jun 2022 07:32:54 -0700 (PDT) Received: from localhost.localdomain ([223.104.160.3]) by smtp.gmail.com with ESMTPSA id o4-20020a1709026b0400b00163de9e9342sm3684354plk.17.2022.06.17.07.32.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Jun 2022 07:32:54 -0700 (PDT) From: Binglei Wang X-Google-Original-From: Binglei Wang To: mhiramat@kernel.org Cc: naveen.n.rao@linux.ibm.com, anil.s.keshavamurthy@intel.com, davem@davemloft.net, linux-kernel@vger.kernel.org, l3b2w1 Subject: [PATCH] kprobes: check the prameter offset in _kprobe_addr() Date: Fri, 17 Jun 2022 22:32:45 +0800 Message-Id: <1655476365-21662-1-git-send-email-l3b2w1@gmail.com> X-Mailer: git-send-email 2.7.4 X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: l3b2w1 I encounter a problem when using kprobe. There is no checkping about the parameter offset in _kprobe_address(). a. execute command with a valid address, it succeed. echo 'p:km __kmalloc+4099' > kprobe_events In reality, __kmalloc+4099 points to free_debug_processing+579. so we end up with: p:kprobes/kp __kmalloc+4099 b. execute command with an invalid address, failing because of addr crossing instruction boundary echo 'p:km __kmalloc+4096' > kprobe_events In reality, __kmalloc+4096 points to free_debug_processing+576. Thus, if not checkping the offset, it could point to anywhere, may succeed with a valid addr, or fail with an invalid addr. that's not what we want already. When registering a kprobe to debug something, either supplied with a symbol name through the sysfs trace interface, or programming kp.addr with a specific value in a module, that means the target function to be probed by us is determined. With or whitout an offset(0 or !0), it should be limited to be whithin the function body. to avoid ending up with a different and unknown function. Maybe it's better to check it. Thank you to review this! Signed-off-by: l3b2w1 --- kernel/kprobes.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/kernel/kprobes.c b/kernel/kprobes.c index f214f8c..d5b907a 100644 --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -1449,6 +1449,9 @@ static kprobe_opcode_t * _kprobe_addr(kprobe_opcode_t *addr, const char *symbol_name, unsigned long offset, bool *on_func_entry) { + unsigned long addr_offset; + unsigned long symbol_size; + if ((symbol_name && addr) || (!symbol_name && !addr)) goto invalid; @@ -1465,14 +1468,20 @@ _kprobe_addr(kprobe_opcode_t *addr, const char *symbol_name, return ERR_PTR(-ENOENT); } + if (!kallsyms_lookup_size_offset((unsigned long)addr, + &symbol_size, &addr_offset)) + return ERR_PTR(-ENOENT); + + /* Guarantee probed addr do not step over more than one function */ + if (offset >= symbol_size || offset >= symbol_size - addr_offset) + goto invalid; + /* - * So here we have @addr + @offset, displace it into a new - * @addr' + @offset' where @addr' is the symbol start address. + * @addr is the symbol start address + * @offset is the real 'offset' relative to start address */ - addr = (void *)addr + offset; - if (!kallsyms_lookup_size_offset((unsigned long)addr, NULL, &offset)) - return ERR_PTR(-ENOENT); - addr = (void *)addr - offset; + addr -= addr_offset; + offset += addr_offset; /* * Then ask the architecture to re-combine them, taking care of -- 2.7.4