This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug dynamic-link/21269] i386 sigaction sa_restorer handling is wrong


https://sourceware.org/bugzilla/show_bug.cgi?id=21269

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |i386
                 CC|                            |fweimer at redhat dot com
          Component|libc                        |dynamic-link

--- Comment #1 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Andy Lutomirski from comment #0)
> glibc does this:
> 
>       if (GLRO(dl_sysinfo_dso) == NULL)
>         {
>           kact.sa_flags |= SA_RESTORER;
> 
>           kact.sa_restorer = ((act->sa_flags & SA_SIGINFO)
>                               ? &restore_rt : &restore);
>         }
> 
> This is correct for the vDSO-present case, but it's subtly wrong for the
> vDSO-not-present case.  For ancient historical reasons, x86_32 Linux (and
> compat on x86_64) interprets SA_RESTORER clear with nonzero sa_restorer as a
> request for stack switching if the SS segment is funny.  This means that
> anything that tries to mix glibc's signal handling with segmentation is
> randomly broken depending on what garbage lands in sa_restorer.  (Also, it's
> just bad form to pass uninitialized data into the kernel.)
> 
> The fix should be trivial:
> 
>     else
>       kact.sa_restorer = NULL;
> 
> or similar.

I think I'll take your word for this.  This seems an 

Do you see occasional crashes due to this?  Can they be triggered somehow, or
are they spontaneous?

> I can send a short test case if needed.

Do you have a copyright assignment for glibc?  If not, I'd prefer if you could
describe what we need to test instead, so that we can write our own test case. 
(And yes, we'd very much like to have a test case for this.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]