[PATCH v2 00/20] Fix handling of compat_siginfo_t
luto at amacapital.net
Sat Nov 7 21:09:27 PST 2015
On Wed, Nov 4, 2015 at 4:50 PM, Amanieu d'Antras <amanieu at gmail.com> wrote:
> One issue that isn't resolved in this series is sending signals between a 32-bit
> process and 64-bit process. Sending a si_int will work correctly, but a si_ptr
> value will likely get corrupted due to the different layouts of the 32-bit and
> 64-bit siginfo_t structures.
This is so screwed up it's not even funny.
A 64-bit big-endian compat calls rt_sigqueueinfo. It passes in (among
other things) a sigval_t. The kernel can choose to interpret it as a
pointer (call it p) or an integer (call it i). Then (unsigned long)p
= (i<<32) | [something]. If the number was an integer to begin with
*and* user code zeroed out the mess first, then [something] will be 0.
Regardless, p != i unless they're both zero.
If the result gets delivered to a signalfd, then it's plausible that
everything could work. If it gets delivered to a 64-bit siginfo, then
all is well because it's in exactly the same screwed up state it was
in when the signal gets sent.
If, however, it's delivered to a compat task, wtf is the kernel
supposed to do? We're effectively supposed to convert a 64-bit
sigval_t to a 32-bit sigval_t. On a little-endian architecture, we
can fudge it because it doesn't really matter whether we consider the
pointer or the int to be authoritative. I think that, on big-endian,
BTW, x86 has its own set of screwups here. Somehow cr2 and error_code
ended up as part of ucontext instead of siginfo, which makes
absolutely no sense to me and bloats task_struct.
More information about the linux-arm-kernel