| 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
| ||
|
Message-ID: <5511CE58.3020507@ezchip.com>
Date: Tue, 24 Mar 2015 16:51:36 -0400
From: Chris Metcalf <cmetcalf@...hip.com>
To: Catalin Marinas <catalin.marinas@....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>,
Martin Schwidefsky <schwidefsky@...ibm.com>,
Heiko Carstens <heiko.carstens@...ibm.com>,
"James E.J. Bottomley" <jejb@...isc-linux.org>,
Helge Deller <deller@....de>
Subject: Re: [PATCH] tile: use si_int instead of si_ptr for compat_siginfo
(+s390 and parisc maintainers)
On 03/23/2015 08:02 AM, Catalin Marinas wrote:
> 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.
To be honest, I'm not even sure what path sets si_code < 0. I see
that that is SI_FROMUSER(), but I don't see where it gets set.
In any case, I guess a risk here is that of a 64-bit process doing a
sigqueue()
targeting a 32-bit process. It seems like an impossible problem for the
32-bit process to know whether the 64-bit process wrote a 32-bit pointer
to the 64-bit sival_ptr field (and thus we should deliver the second 32-bit
word of the union sigval to the 32-bit user), or if the 64-bit process wrote
a 32-bit value to the 32-bit sival_int field (and thus we should deliver
the
first 32-bit word of the union sigval). Little-endian makes some things
a little bit easier :-)
All that said, my inclination is to use si_int here just because that's what
we're using elsewhere. But I'm not entirely sure either.
>> /* 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.
So here we presumably have the reverse problem, which is a 32-bit
process doing a sigqueue() to a 64-bit process. If the 64-bit process
inspects the sival_ptr, it does seem like it might find garbage in it.
But it also doesn't seem portable in much the same way as the
reverse direction; for a 32-bit process to signal a 64-bit process means
the 64-bit process can't read si_ptr or it will get different values
depending on what endianness is in force, so garbage is only part
of the problem.
I was modeling this code on the very similar code for parisc and s390.
I've added their maintainers to the cc list for this email thread.
I see that x86 uses si_ptr in its equivalent code, but of course it has no
issues with big-endianness.
--
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com
--
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/
Powered by blists - more mailing lists