patches.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Jann Horn <jannh@google.com>,
	Jens Wiklander <jens.wiklander@linaro.org>,
	Rouven Czerwinski <rouven.czerwinski@linaro.org>,
	Sasha Levin <sashal@kernel.org>,
	op-tee@lists.trustedfirmware.org
Subject: [PATCH AUTOSEL 5.15 4/5] tee: Prevent size calculation wraparound on 32-bit kernels
Date: Wed,  4 Jun 2025 07:50:32 -0400	[thread overview]
Message-ID: <20250604115033.209492-4-sashal@kernel.org> (raw)
In-Reply-To: <20250604115033.209492-1-sashal@kernel.org>

From: Jann Horn <jannh@google.com>

[ Upstream commit 39bb67edcc582b3b386a9ec983da67fa8a10ec03 ]

The current code around TEE_IOCTL_PARAM_SIZE() is a bit wrong on
32-bit kernels: Multiplying a user-provided 32-bit value with the
size of a structure can wrap around on such platforms.

Fix it by using saturating arithmetic for the size calculation.

This has no security consequences because, in all users of
TEE_IOCTL_PARAM_SIZE(), the subsequent kcalloc() implicitly checks
for wrapping.

Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Tested-by: Rouven Czerwinski <rouven.czerwinski@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

**YES** This commit should be backported to stable kernel trees. Here's
my extensive analysis: ## Vulnerability Analysis The commit fixes a real
integer overflow vulnerability in the TEE (Trusted Execution
Environment) subsystem on 32-bit kernels. The issue occurs in the
`TEE_IOCTL_PARAM_SIZE()` macro defined as: ```c #define
TEE_IOCTL_PARAM_SIZE(x) (sizeof(struct tee_param) * (x)) ``` Where
`struct tee_ioctl_param` is 32 bytes (4 × 8-byte fields). On 32-bit
systems, when a user provides a large `num_params` value, the
multiplication `32 * num_params` can wrap around, potentially bypassing
buffer length validation checks. ## Specific Vulnerable Code Locations
The vulnerable pattern appears in 4 locations in
`drivers/tee/tee_core.c`: 1. **Line 490**: `tee_ioctl_open_session()` -
`sizeof(arg) + TEE_IOCTL_PARAM_SIZE(arg.num_params) != buf.buf_len` 2.
**Line 568**: `tee_ioctl_invoke()` - `sizeof(arg) +
TEE_IOCTL_PARAM_SIZE(arg.num_params) != buf.buf_len` 3. **Line 702**:
`tee_ioctl_supp_recv()` - `sizeof(*uarg) +
TEE_IOCTL_PARAM_SIZE(num_params) != buf.buf_len` 4. **Line 801**:
`tee_ioctl_supp_send()` - `sizeof(*uarg) +
TEE_IOCTL_PARAM_SIZE(num_params) > buf.buf_len` ## Attack Scenario On
32-bit systems, if `num_params = 0x08000000` (134,217,728), then: -
`TEE_IOCTL_PARAM_SIZE(0x08000000) = 32 * 0x08000000 = 0x100000000` -
This wraps to `0x00000000` on 32-bit systems - The size validation
`sizeof(arg) + 0 != buf.buf_len` could be bypassed - Subsequent
`kcalloc()` would allocate a huge buffer, but the size calculations
would be wrong ## Why This Should Be Backported **Matches "YES" backport
criteria from similar commits:** 1. **Security Fix**: Like Similar
Commit #2 (rtl8188eu security hole) and #4 (gup_benchmark integer
overflow), this prevents user-controlled integer overflow that could
lead to memory corruption. 2. **Small, Contained Change**: The fix uses
the kernel's standard `size_add()` and `size_mul()` helpers from
`linux/overflow.h` - exactly like Similar Commit #3 which was noted as
using `size_add()` for similar protection. 3. **Critical Subsystem**:
TEE handles sensitive cryptographic operations and trusted applications,
making security fixes here particularly important. 4. **Low Regression
Risk**: The fix only adds overflow protection without changing
functionality. The `size_mul()` and `size_add()` functions are well-
tested kernel overflow helpers. 5. **User-Controllable Input**: The
`num_params` value comes directly from user space through ioctl calls,
making this a user-triggerable condition. 6. **Clear Security Impact**:
While the commit states "no security consequences because kcalloc()
implicitly checks for wrapping," this is defense-in-depth - the size
validation should not rely on downstream allocation checks. The fix
pattern exactly matches Similar Commit #4 (mm/gup_benchmark.c) which was
backported for preventing integer overflow in size calculations with
user-provided values. This commit follows the same security principle
and uses the same overflow-safe arithmetic helpers that the kernel has
standardized on for these scenarios.

 drivers/tee/tee_core.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c
index a44e5b53e7a91..a7e89c229fc51 100644
--- a/drivers/tee/tee_core.c
+++ b/drivers/tee/tee_core.c
@@ -10,6 +10,7 @@
 #include <linux/fs.h>
 #include <linux/idr.h>
 #include <linux/module.h>
+#include <linux/overflow.h>
 #include <linux/slab.h>
 #include <linux/tee_drv.h>
 #include <linux/uaccess.h>
@@ -19,7 +20,7 @@
 
 #define TEE_NUM_DEVICES	32
 
-#define TEE_IOCTL_PARAM_SIZE(x) (sizeof(struct tee_param) * (x))
+#define TEE_IOCTL_PARAM_SIZE(x) (size_mul(sizeof(struct tee_param), (x)))
 
 #define TEE_UUID_NS_NAME_SIZE	128
 
@@ -493,7 +494,7 @@ static int tee_ioctl_open_session(struct tee_context *ctx,
 	if (copy_from_user(&arg, uarg, sizeof(arg)))
 		return -EFAULT;
 
-	if (sizeof(arg) + TEE_IOCTL_PARAM_SIZE(arg.num_params) != buf.buf_len)
+	if (size_add(sizeof(arg), TEE_IOCTL_PARAM_SIZE(arg.num_params)) != buf.buf_len)
 		return -EINVAL;
 
 	if (arg.num_params) {
@@ -571,7 +572,7 @@ static int tee_ioctl_invoke(struct tee_context *ctx,
 	if (copy_from_user(&arg, uarg, sizeof(arg)))
 		return -EFAULT;
 
-	if (sizeof(arg) + TEE_IOCTL_PARAM_SIZE(arg.num_params) != buf.buf_len)
+	if (size_add(sizeof(arg), TEE_IOCTL_PARAM_SIZE(arg.num_params)) != buf.buf_len)
 		return -EINVAL;
 
 	if (arg.num_params) {
@@ -705,7 +706,7 @@ static int tee_ioctl_supp_recv(struct tee_context *ctx,
 	if (get_user(num_params, &uarg->num_params))
 		return -EFAULT;
 
-	if (sizeof(*uarg) + TEE_IOCTL_PARAM_SIZE(num_params) != buf.buf_len)
+	if (size_add(sizeof(*uarg), TEE_IOCTL_PARAM_SIZE(num_params)) != buf.buf_len)
 		return -EINVAL;
 
 	params = kcalloc(num_params, sizeof(struct tee_param), GFP_KERNEL);
@@ -804,7 +805,7 @@ static int tee_ioctl_supp_send(struct tee_context *ctx,
 	    get_user(num_params, &uarg->num_params))
 		return -EFAULT;
 
-	if (sizeof(*uarg) + TEE_IOCTL_PARAM_SIZE(num_params) > buf.buf_len)
+	if (size_add(sizeof(*uarg), TEE_IOCTL_PARAM_SIZE(num_params)) > buf.buf_len)
 		return -EINVAL;
 
 	params = kcalloc(num_params, sizeof(struct tee_param), GFP_KERNEL);
-- 
2.39.5


  parent reply	other threads:[~2025-06-04 11:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-04 11:50 [PATCH AUTOSEL 5.15 1/5] watchdog: da9052_wdt: respect TWDMIN Sasha Levin
2025-06-04 11:50 ` [PATCH AUTOSEL 5.15 2/5] bus: fsl-mc: increase MC_CMD_COMPLETION_TIMEOUT_MS value Sasha Levin
2025-06-04 11:50 ` [PATCH AUTOSEL 5.15 3/5] ARM: OMAP2+: Fix l4ls clk domain handling in STANDBY Sasha Levin
2025-06-04 11:50 ` Sasha Levin [this message]
2025-06-04 11:50 ` [PATCH AUTOSEL 5.15 5/5] Revert "bus: ti-sysc: Probe for l4_wkup and l4_cfg interconnect devices first" Sasha Levin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250604115033.209492-4-sashal@kernel.org \
    --to=sashal@kernel.org \
    --cc=jannh@google.com \
    --cc=jens.wiklander@linaro.org \
    --cc=op-tee@lists.trustedfirmware.org \
    --cc=patches@lists.linux.dev \
    --cc=rouven.czerwinski@linaro.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).