Re: [PATCH v2 1/4] copy_sighand: Handle architectures where sizeof(unsigned long) < sizeof(u64)
David Hildenbrand <[email protected]>
| Newsgroups | gmane.linux.ports.ppc.embedded,gmane.linux.kernel.mm,gmane.linux.kernel,gmane.linux.ports.riscv,gmane.linux.block,gmane.linux.file-systems,gmane.linux.kernel.cgroups,gmane.linux.kernel.lsm,gmane.linux.network,gmane.linux.kernel.perf.user,gmane.comp.security.apparmor,gmane.linux.ports.alpha,gmane.linux.kernel.arc,gmane.linux.ports.arm.kernel,gmane.linux.ports.hexagon,gmane.linux.ports.mips,gmane.linux.ports.parisc,gmane.linux.ports.sh.devel,gmane.linux.ports.sparc,gmane.linux.uml.devel,gmane.linux.kernel.stable |
|---|---|
| Message-ID | <[email protected]> |
On 01.09.25 15:09, Simon Schuster via B4 Relay wrote: > From: Simon Schuster <[email protected]> > > With the introduction of clone3 in commit 7f192e3cd316 ("fork: add > clone3") the effective bit width of clone_flags on all architectures was > increased from 32-bit to 64-bit. However, the signature of the copy_* > helper functions (e.g., copy_sighand) used by copy_process was not > adapted. > > As such, they truncate the flags on any 32-bit architectures that > supports clone3 (arc, arm, csky, m68k, microblaze, mips32, openrisc, > parisc32, powerpc32, riscv32, x86-32 and xtensa). > > For copy_sighand with CLONE_CLEAR_SIGHAND being an actual u64 > constant, this triggers an observable bug in kernel selftest > clone3_clear_sighand: > > if (clone_flags & CLONE_CLEAR_SIGHAND) > > in function copy_sighand within fork.c will always fail given: > > unsigned long /* == uint32_t */ clone_flags > #define CLONE_CLEAR_SIGHAND 0x100000000ULL > > This commit fixes the bug by always passing clone_flags to copy_sighand > via their declared u64 type, invariant of architecture-dependent integer > sizes. > > Fixes: b612e5df4587 ("clone3: add CLONE_CLEAR_SIGHAND") > Cc: [email protected] # linux-5.5+ > Signed-off-by: Simon Schuster <[email protected]> > Reviewed-by: Lorenzo Stoakes <[email protected]> > --- (stripping To list) Acked-by: David Hildenbrand <[email protected]> -- Cheers David / dhildenb