linux-kernel - Re: [PATCH] tile: use si_int instead of si_ptr for compat

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 23 Mar 2015 12:02:54 +0000
From:	Catalin Marinas <catalin.marinas@....com>
To:	Chris Metcalf <cmetcalf@...hip.com>
Cc:	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
	ralf@...ux-mips.org, benh@...nel.crashing.org, deller@....de,
	"dingtianhong@...wei.com" <dingtianhong@...wei.com>,
	heiko.carstens@...ibm.com, jejb@...isc-linux.org,
	Will Deacon <Will.Deacon@....com>,
	"lizefan@...wei.com" <lizefan@...wei.com>,
	Bamvor Jian Zhang <bamvor.zhangjian@...wei.com>,
	mpe@...erman.id.au, hpa@...or.com, schwidefsky@...ibm.com,
	paulus@...ba.org, tglx@...utronix.de, mingo@...hat.com,
	davem@...emloft.net,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] tile: use si_int instead of si_ptr for compat_siginfo

On Mon, Mar 16, 2015 at 03:04:05PM -0400, Chris Metcalf wrote:
> To be compatible with the generic get_compat_sigevent(), the
> copy_siginfo_to_user32() and thus copy_siginfo_from_user32()
> have to use si_int instead of si_ptr.  Using si_ptr means that
> for the case of ILP32 compat code running in big-endian mode,
> we would end up copying the high 32 bits of the pointer value
> into si_int instead of the desired low 32 bits.
> 
> Signed-off-by: Chris Metcalf <cmetcalf@...hip.com>
> Cc: Catalin Marinas <catalin.marinas@....com>
> ---
>  arch/tile/kernel/compat_signal.c | 9 +++------
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/tile/kernel/compat_signal.c b/arch/tile/kernel/compat_signal.c
> index 8c5abf2e4794..bca13054afb4 100644
> --- a/arch/tile/kernel/compat_signal.c
> +++ b/arch/tile/kernel/compat_signal.c
> @@ -68,7 +68,7 @@ int copy_siginfo_to_user32(struct compat_siginfo __user *to, const siginfo_t *fr
>  	if (from->si_code < 0) {
>  		err |= __put_user(from->si_pid, &to->si_pid);
>  		err |= __put_user(from->si_uid, &to->si_uid);
> -		err |= __put_user(ptr_to_compat(from->si_ptr), &to->si_ptr);
> +		err |= __put_user(from->si_int, &to->si_int);
>  	} else {
>  		/*
>  		 * First 32bits of unions are always present:
> @@ -93,8 +93,7 @@ int copy_siginfo_to_user32(struct compat_siginfo __user *to, const siginfo_t *fr
>  			break;
>  		case __SI_TIMER >> 16:
>  			err |= __put_user(from->si_overrun, &to->si_overrun);
> -			err |= __put_user(ptr_to_compat(from->si_ptr),
> -					  &to->si_ptr);
> +			err |= __put_user(from->si_int, &to->si_int);
>  			break;

It's usually the __SI_TIMER and __SI_MESGQ cases that matters here (the
latter already handled). I'm not entirely sure about the si_code < 0
change.

>  			 /* This is not generated by the kernel as of now.  */
>  		case __SI_RT >> 16:
> @@ -110,7 +109,6 @@ int copy_siginfo_to_user32(struct compat_siginfo __user *to, const siginfo_t *fr
>  int copy_siginfo_from_user32(siginfo_t *to, struct compat_siginfo __user *from)
>  {
>  	int err;
> -	u32 ptr32;
>  
>  	if (!access_ok(VERIFY_READ, from, sizeof(struct compat_siginfo)))
>  		return -EFAULT;
> @@ -121,8 +119,7 @@ int copy_siginfo_from_user32(siginfo_t *to, struct compat_siginfo __user *from)
>  
>  	err |= __get_user(to->si_pid, &from->si_pid);
>  	err |= __get_user(to->si_uid, &from->si_uid);
> -	err |= __get_user(ptr32, &from->si_ptr);
> -	to->si_ptr = compat_ptr(ptr32);
> +	err |= __get_user(to->si_int, &from->si_int);

We have a memset(to, 0, sizeof(*to)) on arm64 in this function but I
can't see it on tile. Some members or even half of si_ptr would be left
uninitialised.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/