From: Andrea Cervesato via ltp <ltp@lists.linux.it>
To: "Wei Gao" <wegao@suse.com>, <ltp@lists.linux.it>
Subject: Re: [LTP] [PATCH v1] ioctl_pidfd02.c: fix clone3 EFAULT in 32-bit compat mode due to sign extension
Date: Wed, 11 Feb 2026 16:29:12 +0100 [thread overview]
Message-ID: <DGC8MPCRC69D.32BXXF7Y4L63S@suse.com> (raw)
In-Reply-To: <20260125063035.31171-1-wegao@suse.com>
Hi!
On Sun Jan 25, 2026 at 7:30 AM CET, Wei Gao via ltp wrote:
> When running 32-bit binaries on a 64-bit kernel (compat mode), the user
> stack is often mapped in the upper range of the 32-bit address space
> (e.g., 0xffxxxxxx).
>
> Directly casting a 32-bit pointer to uint64_t for the args->pidfd field
> in struct clone_args can trigger sign extension if the pointer's MSB
> (Most Significant Bit) is 1. For example, a 32-bit user address
> 0xff80e0bc is incorrectly sign-extended to 0xfffffffffff80e0bc.
>
> When the 64-bit kernel executes put_user(), it identifies this address
> as being in the 64-bit kernel canonical range rather than user space,
> leading to a failed access_ok() check and returning -EFAULT.
>
> This patch fixes the issue by double-casting through uintptr_t to
> ensure zero-extension, keeping the address within the valid 32-bit
> user-space range from the kernel's perspective.
The git commit message is unnecesarily complex. We can say:
Correct the 32-bit pointer u64 conversion for args->pidfd. Direct
casting from a 32-bit pointer to a 64-bit integer was causing incorrect
sign-extension. Using (uint64_t)(uintptr_t) ensures a valid zero-padded
64-bit address.
>
> Signed-off-by: Wei Gao <wegao@suse.com>
> ---
> testcases/kernel/syscalls/ioctl/ioctl_pidfd02.c | 2 +-
> testcases/kernel/syscalls/ioctl/ioctl_pidfd03.c | 2 +-
> testcases/kernel/syscalls/ioctl/ioctl_pidfd04.c | 2 +-
> testcases/kernel/syscalls/ioctl/ioctl_pidfd05.c | 2 +-
> testcases/kernel/syscalls/ioctl/ioctl_pidfd06.c | 2 +-
> 5 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/testcases/kernel/syscalls/ioctl/ioctl_pidfd02.c b/testcases/kernel/syscalls/ioctl/ioctl_pidfd02.c
> index c6f8a02fe..cc44a1bb5 100644
> --- a/testcases/kernel/syscalls/ioctl/ioctl_pidfd02.c
> +++ b/testcases/kernel/syscalls/ioctl/ioctl_pidfd02.c
> @@ -27,7 +27,7 @@ static void run(unsigned int isolate)
>
> if (isolate) {
> args->flags = CLONE_PIDFD | CLONE_NEWUSER | CLONE_NEWPID;
> - args->pidfd = (uint64_t)&pidfd;
> + args->pidfd = (uint64_t)(uintptr_t)&pidfd;
> args->exit_signal = SIGCHLD;
>
> pid_child = SAFE_CLONE(args);
> diff --git a/testcases/kernel/syscalls/ioctl/ioctl_pidfd03.c b/testcases/kernel/syscalls/ioctl/ioctl_pidfd03.c
> index 2c785004c..53223c0a5 100644
> --- a/testcases/kernel/syscalls/ioctl/ioctl_pidfd03.c
> +++ b/testcases/kernel/syscalls/ioctl/ioctl_pidfd03.c
> @@ -24,7 +24,7 @@ static void run(void)
> memset(args, 0, sizeof(struct tst_clone_args));
>
> args->flags = CLONE_PIDFD | CLONE_NEWUSER | CLONE_NEWPID;
> - args->pidfd = (uint64_t)&pidfd;
> + args->pidfd = (uint64_t)(uintptr_t)&pidfd;
> args->exit_signal = SIGCHLD;
>
> pid_child = SAFE_CLONE(args);
> diff --git a/testcases/kernel/syscalls/ioctl/ioctl_pidfd04.c b/testcases/kernel/syscalls/ioctl/ioctl_pidfd04.c
> index ff4316068..0b0e4053c 100644
> --- a/testcases/kernel/syscalls/ioctl/ioctl_pidfd04.c
> +++ b/testcases/kernel/syscalls/ioctl/ioctl_pidfd04.c
> @@ -26,7 +26,7 @@ static void run(void)
> info->mask = PIDFD_INFO_EXIT;
>
> args->flags = CLONE_PIDFD | CLONE_NEWUSER | CLONE_NEWPID;
> - args->pidfd = (uint64_t)&pidfd;
> + args->pidfd = (uint64_t)(uintptr_t)&pidfd;
> args->exit_signal = SIGCHLD;
>
> pid_child = SAFE_CLONE(args);
> diff --git a/testcases/kernel/syscalls/ioctl/ioctl_pidfd05.c b/testcases/kernel/syscalls/ioctl/ioctl_pidfd05.c
> index 278e64cef..a921b6b05 100644
> --- a/testcases/kernel/syscalls/ioctl/ioctl_pidfd05.c
> +++ b/testcases/kernel/syscalls/ioctl/ioctl_pidfd05.c
> @@ -36,7 +36,7 @@ static void run(void)
> info_invalid->dummy = 1;
>
> args->flags = CLONE_PIDFD | CLONE_NEWUSER | CLONE_NEWPID;
> - args->pidfd = (uint64_t)&pidfd;
> + args->pidfd = (uint64_t)(uintptr_t)&pidfd;
> args->exit_signal = SIGCHLD;
>
> pid_child = SAFE_CLONE(args);
> diff --git a/testcases/kernel/syscalls/ioctl/ioctl_pidfd06.c b/testcases/kernel/syscalls/ioctl/ioctl_pidfd06.c
> index 95c09dbda..9e78ece82 100644
> --- a/testcases/kernel/syscalls/ioctl/ioctl_pidfd06.c
> +++ b/testcases/kernel/syscalls/ioctl/ioctl_pidfd06.c
> @@ -26,7 +26,7 @@ static void run(void)
> info->mask = PIDFD_INFO_EXIT;
>
> args->flags = CLONE_PIDFD | CLONE_NEWUSER | CLONE_NEWPID;
> - args->pidfd = (uint64_t)&pidfd;
> + args->pidfd = (uint64_t)(uintptr_t)&pidfd;
> args->exit_signal = SIGCHLD;
>
> pid_child = SAFE_CLONE(args);
At this point I would define a macro as following and use it around the
tests when it's needed:
#define TST_PTR_TO_UINT(x) ( (uint64_t)(uintptr_t)(x) )
--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2026-02-11 15:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-25 6:30 [LTP] [PATCH v1] ioctl_pidfd02.c: fix clone3 EFAULT in 32-bit compat mode due to sign extension Wei Gao via ltp
2026-02-11 15:29 ` Andrea Cervesato via ltp [this message]
2026-02-13 2:36 ` [LTP] [PATCH v2] " Wei Gao via ltp
2026-02-13 9:27 ` Cyril Hrubis
2026-02-13 10:25 ` Andrea Cervesato via ltp
2026-02-13 10:03 ` [LTP] [PATCH v3] " Wei Gao via ltp
2026-02-17 13:14 ` Andrea Cervesato via ltp
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=DGC8MPCRC69D.32BXXF7Y4L63S@suse.com \
--to=ltp@lists.linux.it \
--cc=andrea.cervesato@suse.com \
--cc=wegao@suse.com \
/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