All of lore.kernel.org
 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 6.12 5/6] tee: Prevent size calculation wraparound on 32-bit kernels
Date: Wed,  4 Jun 2025 07:49:57 -0400	[thread overview]
Message-ID: <20250604114959.209031-5-sashal@kernel.org> (raw)
In-Reply-To: <20250604114959.209031-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 d113679b1e2d7..acc7998758ad8 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_core.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
 
@@ -487,7 +488,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) {
@@ -565,7 +566,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) {
@@ -699,7 +700,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);
@@ -798,7 +799,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


WARNING: multiple messages have this Message-ID (diff)
From: Sasha Levin via OP-TEE <op-tee@lists.trustedfirmware.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Jann Horn <jannh@google.com>,
	Rouven Czerwinski <rouven.czerwinski@linaro.org>,
	Sasha Levin <sashal@kernel.org>,
	op-tee@lists.trustedfirmware.org
Subject: [PATCH AUTOSEL 6.12 5/6] tee: Prevent size calculation wraparound on 32-bit kernels
Date: Wed,  4 Jun 2025 07:49:57 -0400	[thread overview]
Message-ID: <20250604114959.209031-5-sashal@kernel.org> (raw)
In-Reply-To: <20250604114959.209031-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 d113679b1e2d7..acc7998758ad8 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_core.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
 
@@ -487,7 +488,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) {
@@ -565,7 +566,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) {
@@ -699,7 +700,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);
@@ -798,7 +799,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: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-04 11:49 [PATCH AUTOSEL 6.12 1/6] fbcon: Make sure modelist not set on unregistered console Sasha Levin
2025-06-04 11:49 ` [PATCH AUTOSEL 6.12 2/6] watchdog: da9052_wdt: respect TWDMIN Sasha Levin
2025-06-04 11:49 ` [PATCH AUTOSEL 6.12 3/6] bus: fsl-mc: increase MC_CMD_COMPLETION_TIMEOUT_MS value Sasha Levin
2025-06-04 11:49 ` [PATCH AUTOSEL 6.12 4/6] ARM: OMAP2+: Fix l4ls clk domain handling in STANDBY Sasha Levin
2025-06-04 11:49 ` Sasha Levin [this message]
2025-06-04 11:49   ` [PATCH AUTOSEL 6.12 5/6] tee: Prevent size calculation wraparound on 32-bit kernels Sasha Levin via OP-TEE
2025-06-04 11:49 ` [PATCH AUTOSEL 6.12 6/6] 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=20250604114959.209031-5-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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.