From nobody Tue Feb 10 11:23:42 2026 Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) (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 3A87520E6E5 for ; Fri, 10 Jan 2025 13:43:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.46 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736516585; cv=none; b=dCBh+CqOccIZ5nJLnJRWSz8jUByHkRQ2QjesdUuBG07+zBpFzJ/mJODUGbUZCxhL9Qi9CNnfGCSxFp72qdJGtdqqza3G54upSMOKCz/cZT0Gu4G4p0jBW6pZuho4G1Lqq+Hjdj9QVu+Q+HkCaQgp0zh8Dh/OlQ2A3WRB5t9xD2Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736516585; c=relaxed/simple; bh=oBRbViGsjo+9//tesyPeMnUIZ2uDlpGOj+/95a2aO6Q=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=j6kL69Lb1ndJ4E/DxaxICDu7L6b3rsxbptcJ/EIlRGOUtJa1mTax4oVzry+51xQr1bMqJ770nyDgXyX44xgdyamRp9jqNvbFsWnUYdbbj2nt5405ZK+gDbGCcjLW3icIuzv8D9LtZdLAArlMVYICUqO/yU5zG03XfPeHFFbe6TI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=Lg5AJtVA; arc=none smtp.client-ip=209.85.128.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="Lg5AJtVA" Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-436341f575fso22231465e9.1 for ; Fri, 10 Jan 2025 05:43:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1736516581; x=1737121381; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=bsVYPyFwzz4xjTS4dQLxlrNi1uKC1eQyiHWIjy65XdA=; b=Lg5AJtVAByJUA5/hSu5zDybVg39DSdIef9O9lO9bP7IRvrFDDFz1yrmZVX7cO8Zyzv GnSGqP4PrPFxEmvAKg1ICSq/Q9y5NtanRck/Mv4aba8KEuwrvAk0x0TRQUs1FgPqEDWe +JcX2DDUY15/0Ef4V4CpeevH1GUiAA7l9oFqTmPR3YwKrKAb8trefSoqoz1D5WbyCqqU tBxl5/TKujHFh/GzMU4XsnWw76aVlHW+mBcZccP2SoFLxFM23iXZDVmJdZ2GfKDBwILd 0svprNlrpp1VPOGrF2WGXRyjOQb0enLPRM1cPovKujkjEeeWWirmoP5k4MX2Rc6gAPyF yPvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736516581; x=1737121381; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=bsVYPyFwzz4xjTS4dQLxlrNi1uKC1eQyiHWIjy65XdA=; b=vE/zkOThtXCMQIwNkEu5Afn9pmZp+o39Lw8OEY4a9dryDw2IRJo9MKl9mySwPDw8++ 4ao+4SG0Bfm+shF4yzV/Ap0W8YQgtSC/MjC9dQFRv7CqGRWXAb6MPvc1s0DFoMG2FeS8 +O9gZOZZGF/7agIeDuAa3/4uB/DUEXYHk9bLvVsQQVusTKg5xnxlFS6WK4LO0sIshEZA lX8Rs/RL6N/BalmuseGTXHlu/JeN6FYcC/bONoeBsJsAUUJlWOmb6+CKxw0jUJTB2Dpt 9eLDcHquFvGB35epvjEBXIei9Y1lKTMlL8PiX0EPO5JOX+6YtOJMlrLsCaeUV/W9G+3h ws4w== X-Gm-Message-State: AOJu0Yx6G5o1C9trraPocSkS3HmFL895PP62oGJ8WCXpd3KWuLU+p1pi KacFEU0fyAUuIf4isA78bwLuPjYRipbZRomMa6Uv4gPC7kMM9HbPf7exjvEd7Qw= X-Gm-Gg: ASbGncs4A6pLMKljX4G3XvwPjxumnMZEusLMyTIvPgclPfMyr7/ibsnrRv/6HfRwpPe xJuAjWbKda/prj2iJGJK+t/Kaz7bQrjR0flH+4hhbJGfnACnmQ/8VozA8kp75U94bIWnzPmQ637 TKQMEd/WpeRDLjVBxSv4eW8TGvi9f9pHDGRqM2/elVP7d18WfSd3kMg0EfkIRoJ2zLBjMYxXscu SMo5tVZmjZyvmzHrAU8Buh+abRl6D6cYkSpCZ/Omxn2ol5CfL0n8/dHqPF6dRND2Zz69LA5/zvf x0yk3g== X-Google-Smtp-Source: AGHT+IE2HEnTZWx0wB4TbxwXVcoultXiaxTF4RQ3DAdC7Ol3VWvcUk3vN/jPNA0DjtUBtbJKy4n3KA== X-Received: by 2002:a05:600c:a09:b0:434:f753:6012 with SMTP id 5b1f17b1804b1-436e26aa593mr110780475e9.17.1736516581599; Fri, 10 Jan 2025 05:43:01 -0800 (PST) Received: from localhost.localdomain ([5.133.47.210]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-436e2e89e14sm87584295e9.33.2025.01.10.05.43.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Jan 2025 05:43:00 -0800 (PST) From: srinivas.kandagatla@linaro.org To: gregkh@linuxfoundation.org Cc: linux-kernel@vger.kernel.org, Ekansh Gupta , stable@kernel.org, Srinivas Kandagatla Subject: [PATCH 2/3] misc: fastrpc: Fix registered buffer page address Date: Fri, 10 Jan 2025 13:42:38 +0000 Message-Id: <20250110134239.123603-3-srinivas.kandagatla@linaro.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20250110134239.123603-1-srinivas.kandagatla@linaro.org> References: <20250110134239.123603-1-srinivas.kandagatla@linaro.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=1876; i=srinivas.kandagatla@linaro.org; h=from:subject; bh=dFJwtxtocIbRba9qrGE+8E40R39qjMCDT8C5edJ34qg=; b=owEBbQGS/pANAwAKAXqh/VnHNFU3AcsmYgBngSPP7hYXeAhrwF5C//jqd3fK+grRaIcpsblB/ U/YDHd+bhKJATMEAAEKAB0WIQQi509axvzi9vce3Y16of1ZxzRVNwUCZ4EjzwAKCRB6of1ZxzRV N22YB/46zb/OBIh0An0/01KCRP1MMgRep0+mLbki555xGnhue87atTnRzZvzFlXO0k2nYM5DqKd VvLqD90c5vdSIG1TEGrQaR3Kp1esn3vOqjOQ2R0EB1xFChUVNmWnNMaWQJ8Jqel7/ZvZZb9ITQS dTcVvp9gn3ES8L5syVlCX7MYBMI2K5KheyHbAs/o4Ior+CSm6xu6QffDqGTaoAZtBVR2OCVMeDF gad3JX56A5NYu7S4NCvoq8RkkNDcLCxHPvTtoGbp97jzXj2it+wGP42ODPjRgAWHjGJ8WzI4bAz MWJe5FvWUyw87GzPuchDRXnVk/S6eWL8T8u1+VrUVE42CcrJ X-Developer-Key: i=srinivas.kandagatla@linaro.org; a=openpgp; fpr=ED6472765AB36EC43B3EF97AD77E3FC0562560D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ekansh Gupta For registered buffers, fastrpc driver sends the buffer information to remote subsystem. There is a problem with current implementation where the page address is being sent with an offset leading to improper buffer address on DSP. This is leads to functional failures as DSP expects base address in page information and extracts offset information from remote arguments. Mask the offset and pass the base page address to DSP. This issue is observed is a corner case when some buffer which is registered with fastrpc framework is passed with some offset by user and then the DSP implementation tried to read the data. As DSP expects base address and takes care of offsetting with remote arguments, passing an offsetted address will result in some unexpected data read in DSP. All generic usecases usually pass the buffer as it is hence is problem is not usually observed. If someone tries to pass offsetted buffer and then tries to compare data at HLOS and DSP end, then the ambiguity will be obser= ved. Fixes: 80f3afd72bd4 ("misc: fastrpc: consider address offset before sending= to DSP") Cc: stable@kernel.org Signed-off-by: Ekansh Gupta Signed-off-by: Srinivas Kandagatla --- drivers/misc/fastrpc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c index 4a971e15d842..891529aa9069 100644 --- a/drivers/misc/fastrpc.c +++ b/drivers/misc/fastrpc.c @@ -992,7 +992,7 @@ static int fastrpc_get_args(u32 kernel, struct fastrpc_= invoke_ctx *ctx) mmap_read_lock(current->mm); vma =3D find_vma(current->mm, ctx->args[i].ptr); if (vma) - pages[i].addr +=3D ctx->args[i].ptr - + pages[i].addr +=3D (ctx->args[i].ptr & PAGE_MASK) - vma->vm_start; mmap_read_unlock(current->mm); =20 --=20 2.25.1