From nobody Sun Jul 26 01:45:48 2026 Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) (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 2D4FC378D7B for ; Fri, 10 Jul 2026 09:02:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.179 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783674160; cv=none; b=HQxU1W6oX8/YNIuhf3gByIaYSTh7sv/wS+iZ5CRhy8V0Y+NdrrMJ/P5vvWNRIFkdz3989TG0J5t8FMFvNv3ghI0dayfs7Yu8s6Z2LXJVS7PVmZ3+tR0BEtB6A14ytQmAoM62MpeKqrqJ+EUU897q3fyb6pvlEFQMZeT/n0XlBMQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783674160; c=relaxed/simple; bh=/wpKpY45DSI4HgdAk0vcydnpSfjw078lWvatlK/8ypM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=SQ7eNu0vNz6tTNwCTzH6/SekegL1IuD/3xQ2avbcMGXjG231JCXOZS4AyWAfmFtiV61lQMmGrFhk0VByh5lUhCj2xeFXSQN7J5cRZfA8TSZ+PcvXVmFILuC7iZeXyrqqIKRbinFhs1ojPM7bYLVHwLu/uTBeS73MAs8ZAqZcmKk= 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=R2dW+uTP; arc=none smtp.client-ip=209.85.214.179 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="R2dW+uTP" Received: by mail-pl1-f179.google.com with SMTP id d9443c01a7336-2cc80b585bfso4618225ad.0 for ; Fri, 10 Jul 2026 02:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783674158; x=1784278958; 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=4L33oMpRIj1SI06g0mcWO4Stxr8HrpjctK5+3kxoMio=; b=R2dW+uTPpofsK5q+f+0DAC8zVk7+XTqEfGXgQLhpn75zqGGhx+2pXlCDxMyxqxwOc2 Vbf+6NoYCJmREsu27ttMiPTQDIo3zJKPVAwSi9203qVgcWea89PdTQ8RN+2crfIT2HXe wK1XdjNT3WfcaA1NhIsJvxeIMBpQ7Cg4m6texJnA82/ORrGrLQskgipoXk+U2Sfu/6NG v/7vj7pv0xXJf/fRy1dCuJPPRJ+kFhqD5zcy3gFbW0idjPqGXvrG9BocZoLMnhVprp5b XvzBiNsXlmoxV4Lcq4FOVTRbQBu3Rn8yJ3pl1BHFaMGGQnnjZaYq+7HVU5mGH4ANciQn 3PRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783674158; x=1784278958; 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=4L33oMpRIj1SI06g0mcWO4Stxr8HrpjctK5+3kxoMio=; b=qGMZ4GtmVr64pFGw2vtr13aERsbzSCWSuh0WJM3IOIr9ug+qbzKbWfGUdZyBd0hzg4 kVUUsd8iNpGUTRmfl9yuUGOCy/fFQWXLabHHMHDL1ABzKmCBqZSq8F+g08i9WfubttX/ CIginmtB51Z8vIQk+oz69Sy1hxkhCG4qfcRi3M3JDuaOWeVmoPET+R3z837EdCachPGh R/dc7LiR//Fqdn7sID2wNSC2xxGJQHq4EGb8L96NIhyhHyfhBmhwaeeb1MIR8yWgyTgd sjQsaZMXjwBpWFeYQwyW0j0T6tt9I2El2IQPb/8uUf0RbOQyUNkW+0tHObEog33JnUBM 5Mwg== X-Forwarded-Encrypted: i=1; AHgh+Rpjcm6H61R11wtJYEHY0kyw6n0UOh/NBfvKWU3VLTVrJfs7xwvEQxLL9b1JevbW7MwPp3IQ4rYlAcfLQJI=@vger.kernel.org X-Gm-Message-State: AOJu0YzOJdTyKt+Hc+wMZHALFtW4qwOX5nObwLf8WmMzypeqbq6DlQ3F NMhvVCFOLTyJAXQNVta/1YNc4CL84ASziwk2nzjBJEhXOHdHhcIbm24IQly9Zzeu X-Gm-Gg: AfdE7clGflnRk48P2lqCUxZTVmNbN5bGeioJsJ87YRy6GxOZnSCWYzr3QeYjLNfz8e8 6GIJc2JD4hrJF3iAsCdGB71R6rEntDYN4FlX8JBxAlD8SjhrYrI+mCNG3a29QWu4JmhRcMTIM9+ lpN2DCaa4KRqXTdffcIBI8wSWUApjSdt2xJyjMMQ0yfjHuTxUkHizDjHt8GdPY/MU1SieTMY6Hp 18He9KVyYZ1U+CXV8pg/rrOeeGoqys/0L5d10cFQzZCnC4iiTVAYgMzGWqCK1IO76o27QbtCrCm UW2UN6N3VBmwYHIsqS7WhMchnoIZ5crjNsLcC/tvX5WBttcEsVNEFc9y3A/sFFyIW5WUHWsB5dL UTGhIR94L3c2zNWMDFoXy5AKLlBsqOXzD4rRb1LRHPx3If8PXyA8lLAZjzsRXmaSRm7y9pCDpgx T1rG2o7RyiZf5Ajs+JHPOkgl5bPpqlXmqdRrI31AqLeesg6nZB1F85osFDpIt3/vkiewFOCid7D qL9SBz59884kAKZDKe+Zg== X-Received: by 2002:a17:903:3c67:b0:2ca:9d5a:8b6c with SMTP id d9443c01a7336-2ccea37d246mr106509045ad.5.1783674158389; Fri, 10 Jul 2026 02:02:38 -0700 (PDT) Received: from DESKTOP-UIAUP5R.localdomain ([116.37.10.184]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ce7b3755a3sm13832775ad.80.2026.07.10.02.02.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Jul 2026 02:02:37 -0700 (PDT) From: Jaewon Yang To: Peter Huewe , Jarkko Sakkinen Cc: Jason Gunthorpe , linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org, security@kernel.org Subject: [PATCH] tpm: Reject reads outside the response buffer Date: Fri, 10 Jul 2026 18:02:17 +0900 Message-ID: <20260710090217.191289-1-yong010301@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: quoted-printable Content-Type: text/plain; charset="utf-8" tpm_common_read() clamps the transfer length to priv->response_length but does not validate the file offset (*off) before using it to index the fixed TPM_BUFSIZE-byte priv->data_buffer: ret_size =3D min_t(ssize_t, size, priv->response_length); copy_to_user(buf, priv->data_buffer + *off, ret_size); memset(priv->data_buffer + *off, 0, ret_size); Sequential read() keeps *off in range, but the fops use the legacy .read callback and neither tpm_open() nor tpmrm_open() calls nonseekable_open(), so FMODE_PREAD stays set and pread(2) passes an arbitrary offset straight into *off. An out-of-range offset then accesses memory beyond data_buffer, causing an out-of-bounds read through copy_to_user() and, when the copy succeeds, an out-of-bounds zero-write through memset(). Reject any read whose offset and length leave the response buffer. Fixes: 9488585b21be ("tpm: add support for partial reads") Cc: stable@vger.kernel.org Signed-off-by: Jaewon Yang --- Notes for reviewers (not part of the commit): Reproduced on a KASAN 6.12 build with a swtpm TPM2 device. After a command leaves a response pending, pread(fd, buf, 16, 0x1400) triggers two slab-out-of-bounds reports, one for the copy_to_user() read and one for the memset() write; on that x86-64 build the faulting access was 962 bytes past a 4344-byte struct tpmrm_priv served from kmalloc-8k. With this patch, out-of-range preads (offset past the buffer, at the end, or an in-range offset whose length crosses the end) return -EINVAL with no KASAN report, while sequential partial reads still return the full response and a normal read after a rejected pread still works. Reaching it needs a process that can open the TPM device and send a command. Access depends on the device-node permissions; the upstream tpm2-tss udev rules set tpmrm devices to mode 0660 with group tss. My reproduction ran as root, so I have not shown non-root reach on a specific distribution or built a privilege-escalation chain. I searched public archives on 2026-07-10 and found no matching report, which does not rule out a private, very recent, or unindexed one. Found through AI-assisted source review; the code path and reproduction were verified by hand. A reproducer and full logs are available on request. drivers/char/tpm/tpm-dev-common.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/char/tpm/tpm-dev-common.c b/drivers/char/tpm/tpm-dev-c= ommon.c index f942c0c8e..dbf049028 100644 --- a/drivers/char/tpm/tpm-dev-common.c +++ b/drivers/char/tpm/tpm-dev-common.c @@ -145,6 +145,16 @@ ssize_t tpm_common_read(struct file *file, char __user= *buf, goto out; } =20 + /* + * Reject reads whose offset and length fall outside the fixed + * response buffer. + */ + if (*off < 0 || *off >=3D TPM_BUFSIZE || + ret_size > TPM_BUFSIZE - *off) { + ret_size =3D -EINVAL; + goto out; + } + rc =3D copy_to_user(buf, priv->data_buffer + *off, ret_size); if (rc) { memset(priv->data_buffer, 0, TPM_BUFSIZE); --=20 2.43.0