Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp535051ybg; Wed, 3 Jun 2020 07:14:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyAWFTvJNOOZcKmvqtCHkcPQIPLlzbz2kT6r41mC9ea6OK3mZDpIAdVLH5vTVgwPCoPLlZQ X-Received: by 2002:aa7:d9d6:: with SMTP id v22mr12772686eds.66.1591193671265; Wed, 03 Jun 2020 07:14:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591193671; cv=none; d=google.com; s=arc-20160816; b=xl+AWHD81olDVdnfi4YTqufe331Rjtrusv1stiyoJa0GK4f7yKqeXjP4fbrjzDmydU uyvYmDYw9iyh9EOtdh961AFEE/42IQFIhiYmmPSc0A+S9cLGej4SqDwH3AwcULmdEh8J C2qc+OqBA4CCvNvc7F+8UURq8HetPLTkZKBWOW4hJUGiauZNwTJZnFMIsopvEfhAvJ52 aKbp5FiCFvHxENPYhj5D30490WS83jkui57yHgCgaqC8V+8w5COtLzgPGrQozarX1QOL oq0kbFqAvaFgldIwQ6lQ3gN9ZcgVblIewtY35Cs+efm0ORoQsqjNYSoL6UMP/w/dVFeu QCaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from; bh=dsu5gOOobB2+bjBMoW1tRsPXy+6WXhwOAXv7iV7Uai4=; b=TlAd4YcUvMq0G8liQNBn7IvN+t4uG1SQTJjwdT/Su481eja0QA+6uruyBdOqcg/3jT gvUWP5Q2nixo/4HbMLZ+qXHdDnG2/h2VTpsepMLFkxhXoqE2MatKdvu5A7Eq9tqn/LnJ lwFxTKrx+f/SXWUr9B3YSJOwPyHc+A0X/pBv/ZzLJEKrGF4CEEZ4SwXI/tNlKlvWc+Lc yswLpUyuyxRIjKBdnbXKrIxC3ld3kjTnowv6tQR9h8PHB+B0kuYE3L4D91L1wJJRolU1 cod6o3JzLz02MCua3lrhYD6vYyIaUGRTxhUyvPASSlThnu/1HRRHXj0FSWEIfePT3rDp wPOg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ly20si1228506ejb.474.2020.06.03.07.14.08; Wed, 03 Jun 2020 07:14:31 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725983AbgFCOMV (ORCPT + 99 others); Wed, 3 Jun 2020 10:12:21 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:38228 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725884AbgFCOMU (ORCPT ); Wed, 3 Jun 2020 10:12:20 -0400 Received: from DGGEMS405-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 47A855205DCCCBE6A13C; Wed, 3 Jun 2020 22:12:10 +0800 (CST) Received: from huawei.com (10.175.124.27) by DGGEMS405-HUB.china.huawei.com (10.3.19.205) with Microsoft SMTP Server id 14.3.487.0; Wed, 3 Jun 2020 22:12:01 +0800 From: Cheng Jian To: , CC: , , , , , , Subject: [PATCH] module: make module symbols visible after init Date: Wed, 3 Jun 2020 14:12:00 +0000 Message-ID: <20200603141200.17745-1-cj.chengjian@huawei.com> X-Mailer: git-send-email 2.17.1 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.175.124.27] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org When lookup the symbols of module by module_kallsyms_lookup_name(), the symbols address is visible only if the module's status isn't MODULE_STATE_UNFORMED, This is problematic. When complete_formation is done, the state of the module is modified to MODULE_STATE_COMING, and the symbol of module is visible to the outside. At this time, the init function of the module has not been called, so if the address of the function symbol has been found and called, it may cause some exceptions. For livepatch module, the relocation information of the livepatch module is completed in init by klp_write_object_relocations(), and the symbol name of the old and new functions are the same. Therefore, when we lookup the symbol, we may get the function address of the livepatch module. a crash can occurs when we call this function. CPU 0 CPU 1 ================================================== load_module add_unformed_module # MODULE_STATE_UNFORMED; post_relocation complete_formation # MODULE_STATE_COMING; ------------------ module_kallsymc_lookup_name("A") call A() # CRASH ------------------ do_init_module klp_write_object_relocations mod->state = MODULE_STATE_LIVE; In commit 0bd476e6c671 ("kallsyms: unexport kallsyms_lookup_name() and kallsyms_on_each_symbol()") restricts the invocation for kernel unexported symbols, but it is still incorrect to make the symbols of non-LIVE modules visible to the outside. Signed-off-by: Cheng Jian --- kernel/module.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/module.c b/kernel/module.c index 64a2b4daaaa5..96c9cb64de57 100644 --- a/kernel/module.c +++ b/kernel/module.c @@ -4220,7 +4220,7 @@ unsigned long module_kallsyms_lookup_name(const char *name) ret = find_kallsyms_symbol_value(mod, colon+1); } else { list_for_each_entry_rcu(mod, &modules, list) { - if (mod->state == MODULE_STATE_UNFORMED) + if (mod->state != MODULE_STATE_LIVE) continue; if ((ret = find_kallsyms_symbol_value(mod, name)) != 0) break; -- 2.17.1