[bug #49023] glibc - hurd_safe_{copyin, copyout, memmove, memset} broken

[Brent Baccala]

URL:
  <http://savannah.gnu.org/bugs/?49023>

                 Summary: glibc - hurd_safe_{copyin, copyout, memmove, memset}
broken
                 Project: The GNU Hurd
            Submitted by: baccala
            Submitted on: Wed 07 Sep 2016 09:02:09 PM GMT
                Category: glibc
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
         Reproducibility: Every Time
              Size (loc): None
         Planned Release: None
                  Effort: 0.00
Wiki-like text discussion box: 

    _______________________________________________________

Details:

The hurd_safe_* routines currently fail to catch memory faults and instead
deliver signals which, if uncaught, terminate the faulting task.

The problem seems to lie in the interaction between the signal preemption code
in hurd/ and sysdeps/mach/hurd/i386/exc2signal.c's exception2signal():


     38     case EXC_BAD_ACCESS:
     39       switch (detail->exc_code)
     40         {
     41         case KERN_INVALID_ADDRESS:
     42         case KERN_MEMORY_FAILURE:
     43           *signo = SIGSEGV;
     44           detail->code = posix ? SEGV_MAPERR : detail->exc_subcode;
     45           break;


Notice that if the 'posix' flag is set, detail->code becomes SEGV_MAPERR
(#defined to be 1), instead of the faulting memory address, which the kernel
provides in exc_subcode.  However, the hurd_signal_preemptor structure, as it
is used in hurd/catch-signal.c (see also the macro HURD_PREEMPT_SIGNAL_P), is
used to compare detail->code to the memory range being accessed by the
hurd_safe_* routine to determine if the signal should be preempted.

The net result is that 1 (SEGV_MAPERR) is never in the memory range being
accessed, so the signal is never preempted.






    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?49023>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/