AFAIK he has sent this exact patch several times before Linus' announcement.
>
> He also missed the fact the security fix part is in 2.3.18ac and 2.2.13pre8
Is it? I can see a single memset(&info, 0, sizeof(info)); there (2.3.18ac4).
There are tens of similar places around the kernel (even in signal.c).
I was planning to fix this once his patch goes in (some weeks ago I've even
sent a patch to l-k).
There are IMHO two approaches how to solve it:
either make sure a 128byte memset is before every siginfo_t setup sequence,
or make the arch signal handlers understand a little bit the siginfo_t
structure and for the well known si_codes they just put_user the fields
related to that si_code as opposed to copy_to_user the whole structure
and only operate with the full 128byte siginfo_t if it came from
sigqueueinfo.
IMHO the latter has advantages in speeding things up (because you will
eliminate most of the 128byte memsets and e.g. copy only 5 32bit words
instead of 128 bytes to userland).
>
> The siginfo stuff seems odd. Its not how non posix rt signals work
As far as I understood rth wanted to do it that way, at least the comment in
signal.c
/* XXX: As an extension, support queueing exactly
one non-rt signal if SA_SIGINFO is set, so that
we can get more detailed information about the
cause of the signal. */
makes me think it.
It makes a lot of sense to use siginfo_t for passing stuff like segfault
address, segfault reason and the like and other Unices do it that way.
What's so odd about that?
Cheers,
Jakub
___________________________________________________________________
Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz
Administrator of SunSITE Czech Republic, MFF, Charles University
___________________________________________________________________
UltraLinux | http://ultra.linux.cz/ | http://ultra.penguin.cz/
Linux version 2.3.18 on a sparc64 machine (1343.49 BogoMips)
___________________________________________________________________
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/