[Bug nptl/14744] New: kill -32 $pid or kill -33 $pid on a process cancels a random thread

[Bug nptl/14744] New: kill -32 $pid or kill -33 $pid on a process cancels a random thread

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=14744

             Bug #: 14744
           Summary: kill -32 $pid or kill -33 $pid on a process cancels a
                    random thread
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: minor
          Priority: P2
         Component: nptl
        AssignedTo: unassigned@sourceware.org
        ReportedBy: bugdal@aerifal.cx
                CC: drepper.fsp@gmail.com
    Classification: Unclassified


Signals 32 and 33 are used internally by NPTL. There's nothing wrong with this,
as they are not advertised as being available to applications (SIGRTMIN shows
up as 34 in multi-threaded applications, if I recall). However, if an outside
process sends these signals, the target process acts on the signal as if it
were a cancellation request for whichever thread happened to receive the
signal. This could cause severe breakage and data corruption in applications
which are not written to use cancellation and lack cleanup handlers.

I am unsure whether the impact is limited to user error (issuing the kill
command manually) or could arise in other ways. In any case, for robustness, I
think the signal handler should be a no-op unless pthread_cancel was really
called in the application.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug nptl/14744] kill -32 $pid or kill -33 $pid on a process cancels a random thread

[carlos at redhat dot com]

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

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com
   Target Milestone|---                         |2.20

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

[Bug nptl/14744] kill -32 $pid or kill -33 $pid on a process cancels a random thread

[neleai at seznam dot cz]

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

Ondrej Bilka <neleai at seznam dot cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |neleai at seznam dot cz

--- Comment #1 from Ondrej Bilka <neleai at seznam dot cz> ---
> I am unsure whether the impact is limited to user error (issuing the kill 
> command manually) or could arise in other ways. In any case, for robustness, I 
> think the signal handler should be a no-op unless pthread_cancel was really 
> called in the application.

That would make problem worse as with that kill would sometimes kill random
thread if a cancellation was called in meantime which is harder to detect as
offending code would be mostly nop.

If this needs handled then by aborting affected process.

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

[Bug nptl/14744] kill -32 $pid or kill -33 $pid on a process cancels a random thread

[bugdal at aerifal dot cx]

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

--- Comment #2 from Rich Felker <bugdal at aerifal dot cx> ---
Perhaps I was not clear. I (hopefully obviously) did not mean that there should
be some global state "this application has called pthread_cancel" which causes
any thread receiving signal 32 or 33 to get cancelled if it's set. The intent
was that pthread_cancel should set the cancellation state on its target (in the
TCB or thread-local storage), and a thread should never act upon cancellation
unless this state is set.

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

[Bug nptl/14744] kill -32 $pid or kill -33 $pid on a process cancels a random thread

[carlos at redhat dot com]

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

--- Comment #3 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Rich Felker from comment #2)
> Perhaps I was not clear. I (hopefully obviously) did not mean that there
> should be some global state "this application has called pthread_cancel"
> which causes any thread receiving signal 32 or 33 to get cancelled if it's
> set. The intent was that pthread_cancel should set the cancellation state on
> its target (in the TCB or thread-local storage), and a thread should never
> act upon cancellation unless this state is set.

The only sanity checking done today is:

  /* Safety check.  It would be possible to call this function for
     other signals and send a signal from another process.  This is not
     correct and might even be a security problem.  Try to catch as
     many incorrect invocations as possible.  */
  if (sig != SIGCANCEL
      || si->si_pid != pid
      || si->si_code != SI_TKILL)
    return;

However the implementation comment seems to indicate desiring support for
cancellation from another process?

      /* We are canceled now.  When canceled by another thread this flag
         is already set but if the signal is directly send (internally or
         from another process) is has to be done here.  */
      int newval = oldval | CANCELING_BITMASK | CANCELED_BITMASK;

I can't imagine under what use case you would support cancelling a thread in a
process from another process?

Comments?

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

[Bug nptl/14744] kill -32 $pid or kill -33 $pid on a process cancels a random thread

[carlos at redhat dot com]

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

--- Comment #4 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Carlos O'Donell from comment #3)
> However the implementation comment seems to indicate desiring support for
> cancellation from another process?
> 
>       /* We are canceled now.  When canceled by another thread this flag
>          is already set but if the signal is directly send (internally or
>          from another process) is has to be done here.  */
>       int newval = oldval | CANCELING_BITMASK | CANCELED_BITMASK;
> 
> I can't imagine under what use case you would support cancelling a thread in
> a process from another process?

The worrisome bit is the "internally" part which seems to indicate there is
some path inside glibc which can't set the target thread's cancellation status
to "cancelling" which would make it impossible to determine if you should or
should not act on the SIGCANCEL signal (assuming AC-enabled).

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

[Bug nptl/14744] kill -32 $pid or kill -33 $pid on a process cancels a random thread

[bugdal at aerifal dot cx]

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

--- Comment #5 from Rich Felker <bugdal at aerifal dot cx> ---
Allowing cancellation from other applications is certainly not desirable, any
moreso than it would be desirable for one process to call free() on a pointer
malloc'd by another process. And anyway, pthread_t is only meaningful within
the context of the process it belongs to.

Technically you could use the tgkill syscall directly to intentionally send a
cancellation signal to a particular target thread in another process (this
would be less insane than sending it to the process and having the kernel
randomly deliver it to one thread). Perhaps the original intent of the code was
to allow something like this, where users might attempt to cancel a stuck
thread as a way to get a process going again. This seems like a really bad idea
though (most apps don't use or support cancellation, and cancelling a thread
that's not written to be cancelled could cause dangerous misbehavior). If
someone really wants to go to that kind of extent to try to "fix" a hung
application, gdb is the right tool, and in fact you can use gdb to call
pthread_cancel on a particular thread or make the thread itself call
pthread_exit.

So, I really don't think there's any sense in trying to allow cancelling
threads from outside the process.

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

[Bug nptl/14744] kill -32 $pid or kill -33 $pid on a process cancels a random thread

[carlos at redhat dot com]

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

--- Comment #6 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Rich Felker from comment #5)
> Allowing cancellation from other applications is certainly not desirable,
> any moreso than it would be desirable for one process to call free() on a
> pointer malloc'd by another process. And anyway, pthread_t is only
> meaningful within the context of the process it belongs to.
> 
> Technically you could use the tgkill syscall directly to intentionally send
> a cancellation signal to a particular target thread in another process (this
> would be less insane than sending it to the process and having the kernel
> randomly deliver it to one thread). Perhaps the original intent of the code
> was to allow something like this, where users might attempt to cancel a
> stuck thread as a way to get a process going again. This seems like a really
> bad idea though (most apps don't use or support cancellation, and cancelling
> a thread that's not written to be cancelled could cause dangerous
> misbehavior). If someone really wants to go to that kind of extent to try to
> "fix" a hung application, gdb is the right tool, and in fact you can use gdb
> to call pthread_cancel on a particular thread or make the thread itself call
> pthread_exit.
> 
> So, I really don't think there's any sense in trying to allow cancelling
> threads from outside the process.

I agree.

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

[Bug nptl/14744] kill -32 $pid or kill -33 $pid on a process cancels a random thread

[fweimer at redhat dot com]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

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

[Bug nptl/14744] kill -32 $pid or kill -33 $pid on a process cancels a random thread

[adhemerval.zanella at linaro dot org]

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

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg
   Target Milestone|---                         |2.34
         Resolution|---                         |FIXED

--- Comment #7 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
I will mark this bug as fixed now that on 2.34
(41c72956179a8ed730d1ac8198015934398fe72b) the cancellation handler is only
installed when pthread_cancel() is called (as the suggestion from comment #1)
and in the signal handler glibc ignores request from other processes.

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