[PATCH] mm/kmemleak: fix scan period truncation on 32-bit platforms

[PATCH] mm/kmemleak: fix scan period truncation on 32-bit platforms

[shao.mingyin]

From: Shao Mingyin <shao.mingyin@zte.com.cn>

mm/kmemleak: fix scan period truncation on 32-bit platforms

kmemleak_write() converts the scan period from seconds to milliseconds
before clamping it to UINT_MAX. On 32-bit kernels, unsigned secs and
MSEC_PER_SEC (1000L) are multiplied in a 32-bit unsigned type. The result
wraps before the clamp can detect overflow.

For example, scan=4294968 produces 704 milliseconds instead of the
UINT_MAX millisecond limit. Perform the multiplication and keep the
intermediate result in unsigned long long, preserving the existing
64-bit behavior and the later msecs_to_jiffies() clamping.

Commit 54dd200c5a25 ("mm/kmemleak: fix possible wrong memory scanning
period") added this clamp, but it cannot work after a 32-bit multiply
has already overflowed.

Signed-off-by: Shao Mingyin <shao.mingyin@zte.com.cn>
---
Build-tested mm/kmemleak.o with W=1 on x86_64 and i386. A freestanding
i386 program checked six inputs, including scan=4294968: the old
arithmetic yields 704 ms and the new arithmetic clamps to UINT_MAX.
This is an arithmetic test, not a kmemleak scanner runtime measurement.


 mm/kmemleak.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 1bca27787df6256d89b54fc3381ca5abb49ac7a6..87274591257f6655655ba5bdd0381f3a38c9404e 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -2455,13 +2455,13 @@ static ssize_t kmemleak_write(struct file *file, const char __user *user_buf,
 		stop_scan_thread();
 	else if (strncmp(buf, "scan=", 5) == 0) {
 		unsigned secs;
-		unsigned long msecs;
+		unsigned long long msecs;
 
 		ret = kstrtouint(buf + 5, 0, &secs);
 		if (ret < 0)
 			goto out;
 
-		msecs = secs * MSEC_PER_SEC;
+		msecs = (unsigned long long)secs * MSEC_PER_SEC;
 		if (msecs > UINT_MAX)
 			msecs = UINT_MAX;
 

base-commit: 84abb955b1015477aa11a96e2f3ac1b938b77f48
-- 
2.43.0

Re: [PATCH] mm/kmemleak: fix scan period truncation on 32-bit platforms

[Lorenzo Stoakes (ARM)]

On Sun, Nov 15, 2026 at 12:47:02AM +0800, shao.mingyin@zte.com.cn wrote:
> From: Shao Mingyin <shao.mingyin@zte.com.cn>
>
> mm/kmemleak: fix scan period truncation on 32-bit platforms
>
> kmemleak_write() converts the scan period from seconds to milliseconds
> before clamping it to UINT_MAX. On 32-bit kernels, unsigned secs and
> MSEC_PER_SEC (1000L) are multiplied in a 32-bit unsigned type. The result
> wraps before the clamp can detect overflow.
>
> For example, scan=4294968 produces 704 milliseconds instead of the
> UINT_MAX millisecond limit. Perform the multiplication and keep the
> intermediate result in unsigned long long, preserving the existing
> 64-bit behavior and the later msecs_to_jiffies() clamping.
>
> Commit 54dd200c5a25 ("mm/kmemleak: fix possible wrong memory scanning
> period") added this clamp, but it cannot work after a 32-bit multiply
> has already overflowed.
>
> Signed-off-by: Shao Mingyin <shao.mingyin@zte.com.cn>

NAK.

this is generated by some AI slopper's script, spamming the kernel. The
patches I looked at were wrong/broken, so no to anything from this person.

They've sent 300 mails in under four weeks spanniing: ata, scsi, target,
ufs, nvme/nvmet, ubifs, ublk, zloop, dm, md, mmc, virtio-blk, mfd, gpio,
pwm, spi, PCI, ASoC, ACPI, net, vfs mount, block partitions, and now mm.

and 17 series across 7 subsystems over the past 23 hours.

We need a way to ban emails from people like this...

--
Cheers, Lorenzo