From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com [209.85.210.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CACF318A93F for ; Sun, 23 Aug 2026 06:07:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787465263; cv=none; b=LaxpTLCHncOTE5+fqZvcH5gipUGHTaKSW1xJkCfbzmzF5u/DTA1wAPaMkfcQraERYUCNa/HY3vNu5zO4CbDzyFvLcB89Dol582j0PYVepSuE+dlgDHsK8zzi6JUHQNEIep2PsKHwEQyGhzaiR5d8uv1PHe1z0U2kjLjtrukGMbo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787465263; c=relaxed/simple; bh=Aict32JxsG+xN20KXZ4+eGbazxup7Ht/42ye8xw1z0o=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=IhplidTvVVLiBIX93cltR6uahQ5UEecHQjgQPw5ORLnPQG1YkVJZQaKWRkOSB8yef7NdXCdkdyiJcYeTJEtTl03dsJMQrF9NkeImsCOKoiHQpcFwrocm8odBzvhciYcnC9TxhP4N8J1TWwD8C/GovEu//RPfdpIK1QkTeu383sY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=JxMGbPTq; arc=none smtp.client-ip=209.85.210.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="JxMGbPTq" Received: by mail-pf1-f174.google.com with SMTP id d2e1a72fcca58-84e04df8c46so3103927b3a.2 for ; Sat, 22 Aug 2026 23:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787465261; x=1788070061; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=TGtr99oRXQabMTcRjnuVAHCf7ojLORqpGOxFBHhRHHM=; b=JxMGbPTqRT0PTEuSH3kbSKQyBCL5cNdwovYg12MShBG/Xv8BjV1OtaNPRyZ9Pz9lqt 7myNUWE846pI4SnLMxz1GFP4pOFkqeWIFzaNZRUXXAlMTzyQMPnUb2lHeO3j6Oi/V3uD SljGge3NE0HKprz/1DgnpDIYz32lsxdzNnGV7ddOD4YV+bRMoNK4qtob6uJRlRFo+fTa se0VfYEvwRUq42pdBWcQJL6uKPXuYNOLgHkxEUswrq9OxHUSoek4kyXB+7yjtzOaKidr 8sb3RI2BtKbKxCM7RYYSZqN+OYIVlLl+jvYT9okSprvEI7hhW+uTwtxcWNiLYEvmtm15 K2JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787465261; x=1788070061; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=TGtr99oRXQabMTcRjnuVAHCf7ojLORqpGOxFBHhRHHM=; b=gVnMY7Lt6JWRcs0dSL+BGdgrhMG5b9xe8r9FJ7N5FRtNtxzyOCskt9uPCj6ZUqjggr mJkvmSpKek4gMST2zxjTyhR8ZjFnVnlPeNGS5R7ldiNISiGQUUpqfaMGKOwd9fmJ41B4 KObcd50CCI56WwS5ERBopRuj5/TpvLgpn/Au1ATcStPWuDinEG7X6KBnm0ib1Krq7kdX ZBJQfAyTF6oTmFKc8Bfm/6EH7MT9Aq2QP96TlXoGDycl4g7lbtofbHqaiVYkmzzpOR3C ZBvFLlmHtzrRZRvf9GaIeNAUBgvcnF+CSeSA/cVfpO772/Xt/WFYQUSVDXIfKKg270Eg 7T4Q== X-Forwarded-Encrypted: i=1; AHgh+RqVV5fdx5ikhDDfNxGC9Iim2FUNa2yrA+I3BQG8HrWQnoKatnqUFynzqqt4iSO2LpvXbNY1q0ap3f5/vfU=@vger.kernel.org X-Gm-Message-State: AFuF++mkE/HTQHhzlFJjKQ7bhOAozZ57pbwJJRIMBmKuulrS1AhaGLk4 zYahIC1mCmy9V4tgWVXQPibp3uQ0L6cnfjZPCh9ZueoEHCGj+vJVB3e5 X-Gm-Gg: AR+sD10EQFixcdtKjrrpeIVRrj2ArAq6a2aq4XgWsf+OB2R6ZufXmn1fgE4oyy019aP g66o1cGsvDCf9BubsTC02pffdIb0ufFd+fKU1NqZCVVEzKvZ4XdoV2NgVke3VI5uz4SUXUK4FHd pM1gEVPWl88wWTNvuG7EEhtZKPZUEHhcqyCXLmXm9skVoJVKxfC0ICPYW9JT/JRuNhQovIv455r h3qyfgvMV/z6JN2yEa+QPn91vRl5ze/0pebODalxje3hEC1NBM2dNRUl/FDKzpBPoHzxvfIvAOe V7RnoYHVTL1iU7rH2k68dXdEkAEF+yq47s8Gcuj2i06/OZc60iF5ycvo6BQWevanX2Jn0DowA1r TwCJggxR3oPMwDLCjby3pi0Ai5rG2RAkPeVF3OotzpepkcBOArPJaow1/EoPWEWgWJ6J4UVMTZK 5LWB8shgH5V6GQsR2iJWsxzS55eNQe9SF/7g9mUTOd8SFGrAh8BakLON/vLF1oBp6u2zVbnZD+9 KwrGLidqidZYf/iNwZJHA89Is4AdDK0 X-Received: by 2002:a05:6a00:a589:b0:851:c2a6:172f with SMTP id d2e1a72fcca58-851f9efcc14mr28246865b3a.7.1787465260946; Sat, 22 Aug 2026 23:07:40 -0700 (PDT) Received: from Harrys-Laptop.hitronhub.home ([2407:4d00:6c05:13e8:edcf:d188:51c8:54cc]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-8520ef0c76fsm1020878b3a.18.2026.08.22.23.07.38 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Sat, 22 Aug 2026 23:07:40 -0700 (PDT) From: Harry Hsu To: pmladek@suse.com Cc: jpoimboe@kernel.org, jikos@kernel.org, mbenes@suse.cz, joe.lawrence@redhat.com, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, Harry Hsu Subject: [PATCH v2] livepatch: Reject livepatches with aliased old_func Date: Sun, 23 Aug 2026 14:07:34 +0800 Message-ID: <20260823060734.58443-1-x90613@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Several symbols can share one address: ffffffff8ed7fef0 t __do_sys_fork ffffffff8ed7fef0 T __ia32_sys_fork ffffffff8ed7fef0 T __x64_sys_fork klp_find_ops() looks the ops up by func->old_func, i.e. by address, so two klp_funcs of the same livepatch naming two of these symbols resolve to the same klp_ops and are both pushed onto one ops->func_stack. This breaks the assumption that a single livepatch contributes at most one entry to any func_stack. klp_ftrace_handler() picks the entry at the top of the stack, but when both entries belong to the same livepatch there is nothing that says which of them should be used in the PATCHED state, and the UNPATCHED state has to end up at the original function either way. klp_check_stack_func() cannot tell them apart either: it asks whether the preceding entry is the original function or another livepatch's replacement, and an aliased sibling is neither. Patching two aliases of one function from a single livepatch was never meaningful, so reject it while the object is being initialized rather than leave the redirection undefined. Compare the resolved old_func of each klp_func against the ones already resolved for the same klp_object and return -EINVAL on a match, naming both symbols so that the offending pair can be found in the livepatch source. Fixes: 3c33f5b99d68 ("livepatch: support for repatching a function") Suggested-by: Petr Mladek Signed-off-by: Harry Hsu --- v2: - Drop the klp_check_stack_func() change. As Petr pointed out, using list_is_last() only made the last entry behave, still checked the aliased sibling's range for the other entries, and did nothing about klp_ftrace_handler() being unable to pick between them. Reject the livepatch in klp_init_object_loaded() instead, as suggested. - Rewrite the changelog around rejecting the configuration rather than around the out-of-bounds read that v1 described. Link: https://lore.kernel.org/all/20260812140232.48079-1-x90613@gmail.com/ kernel/livepatch/core.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c index 28d15ba58a26..c35cf08c27c8 100644 --- a/kernel/livepatch/core.c +++ b/kernel/livepatch/core.c @@ -866,7 +866,7 @@ static void klp_clear_object_relocs(struct klp_patch *patch, static int klp_init_object_loaded(struct klp_patch *patch, struct klp_object *obj) { - struct klp_func *func; + struct klp_func *func, *prev_func; int ret; if (klp_is_module(obj)) { @@ -888,6 +888,21 @@ static int klp_init_object_loaded(struct klp_patch *patch, if (ret) return ret; + /* + * Aliased symbols share one address, so they would resolve to + * the same klp_ops and stack up on a single ops->func_stack, + * leaving the redirection ambiguous. Reject the livepatch. + */ + klp_for_each_func(obj, prev_func) { + if (prev_func == func) + break; + if (prev_func->old_func == func->old_func) { + pr_err("'%s' and '%s' resolve to the same address, aliased symbols are not supported\n", + prev_func->old_name, func->old_name); + return -EINVAL; + } + } + ret = kallsyms_lookup_size_offset((unsigned long)func->old_func, &func->old_size, NULL); if (!ret) { -- 2.43.0