503199 - crash @pthread_detach when destroying Flash plugin instance

Status: RESOLVED FIXED

(External Software Affecting Firefox Graveyard :: Flash (Adobe), defect)

Description

[Karl Tomlinson (:karlt)]

I'm seeing this with (32 and 64-bit) Adobe Flash Player 10.0.22.87 when viewing videos on youtube (but it doesn't seem to happen when the plugin is not playing a video).

Mike, it doesn't look like Mozilla can do much to fix this, but please let me know if I can help at all.

It seems that pthread_detach() is being called on a thread that has already been joined.  This can be observed by setting a break point in pthread_join and pthread_detach before closing a Firefox tab showing a youtube video (or loading another page in the same tab).

[Thread 0x7eaffb90 (LWP 3769) exited]
[Thread 0x76affb90 (LWP 3829) exited]

Breakpoint 1, pthread_join (threadid=1991244688, thread_return=0x0)
    at pthread_join.c:46
46      pthread_join.c: No such file or directory.
        in pthread_join.c
Current language:  auto; currently c
(gdb) bt
#0  pthread_join (threadid=1991244688, thread_return=0x0) at pthread_join.c:46
#1  0xa768b807 in ?? () from /home/karl/.mozilla/plugins/libflashplayer.so
#2  0xa763a9f7 in ?? () from /home/karl/.mozilla/plugins/libflashplayer.so
#3  0xa761ccd0 in ?? () from /home/karl/.mozilla/plugins/libflashplayer.so
#4  0xa7619d41 in ?? () from /home/karl/.mozilla/plugins/libflashplayer.so
#5  0xa744d22a in ?? () from /home/karl/.mozilla/plugins/libflashplayer.so
#6  0xa730d66d in ?? () from /home/karl/.mozilla/plugins/libflashplayer.so
#7  0xa730ddda in ?? () from /home/karl/.mozilla/plugins/libflashplayer.so
#8  0xa73244a0 in ?? () from /home/karl/.mozilla/plugins/libflashplayer.so
#9  0xa7306239 in ?? () from /home/karl/.mozilla/plugins/libflashplayer.so
#10 0xa72f69eb in ?? () from /home/karl/.mozilla/plugins/libflashplayer.so
#11 0xa72c0db3 in ?? () from /home/karl/.mozilla/plugins/libflashplayer.so
#12 0xa6f601b4 in ?? () from /home/karl/.mozilla/plugins/libflashplayer.so
#13 0xa6f5a0c0 in ?? () from /home/karl/.mozilla/plugins/libflashplayer.so
#14 0xa6f52061 in ?? () from /home/karl/.mozilla/plugins/libflashplayer.so
#15 0xa6f56cf4 in ?? () from /home/karl/.mozilla/plugins/libflashplayer.so
#16 0xa79bfb91 in nsNPAPIPluginInstance::Stop (this=0x96ffa140)
    at /home/karl/moz/dev/modules/plugin/base/src/nsNPAPIPluginInstance.cpp:878
#17 0xa8b1513d in DoStopPlugin (aInstanceOwner=0x96d04580, aDelayedStop=0)
    at /home/karl/moz/dev/layout/generic/nsObjectFrame.cpp:1926
#18 0xa8b15792 in nsStopPluginRunnable::Run (this=0x96d8a620)
    at /home/karl/moz/dev/layout/generic/nsObjectFrame.cpp:1989
#19 0xb7d43331 in nsThread::ProcessNextEvent (this=0xb6b8f880, mayWait=1,
    result=0xbfd30790) at /home/karl/moz/dev/xpcom/threads/nsThread.cpp:527
---Type <return> to continue, or q <return> to quit---q
Quit
(gdb) p /x 1991244688
$2 = 0x76affb90
(gdb) fin
Run till exit from #0  pthread_join (threadid=1991244688, thread_return=0x0)
    at pthread_join.c:46
0xa768b807 in ?? () from /home/karl/.mozilla/plugins/libflashplayer.so
Value returned is $3 = 0
(gdb) fin
Run till exit from #0  0xa768b807 in ?? ()
   from /home/karl/.mozilla/plugins/libflashplayer.so
0xa763a9f7 in ?? () from /home/karl/.mozilla/plugins/libflashplayer.so
(gdb)
Run till exit from #0  0xa763a9f7 in ?? ()
   from /home/karl/.mozilla/plugins/libflashplayer.so

Breakpoint 2, pthread_detach (th=1991244688) at pthread_detach.c:28
28      pthread_detach.c: No such file or directory.
        in pthread_detach.c

Comment 1

[Karl Tomlinson (:karlt)]

I'm not sure of the security implications here.  Exploitablility might depend on whether the memory of the joined thread can be influenced.

Comment 2

[Mike Melanson]

I'll try to reproduce.

Comment 3

[Mike Melanson]

I'm having trouble reproducing this on 32-bit Fedora Core 10 with 10.0.22.87.
At what point is it supposed to crash?

Also, do you suspect that Flash Player is explicitly calling pthread_detach()?
Because I can't find any place in our code where that happens.

Comment 4

[Karl Tomlinson (:karlt)]

Attachment: debug session log

I'm seeing this on 32-bit Ubuntu 8.10 (with a remote X server) and on a Gentoo
x86_64 system (with a local X server).

It crashes in pthread_detach (during destruction of the plugin instance).

Whether the pthread_detach actually crashes may depend on memory reuse, but I
was hoping you might be able to catch the pthread_detach call in a debugger.
(Though there may be race conditions or other variables here.)

libflashplayer.so is calling pthread_detach directly (but maybe that's
disguised by a macro somehow).

There's more data in this attached log from a Ubuntu crash that might be
useful to you if you have data to translate offsets to symbols.

Comment 5

[Mike Melanson]

I found a bit of code that performs a pthread_join() followed immediately by a pthread_detach(). I'm pretty sure that's not the way pthreads should be handled. This is also the only place in the codebase that calls pthread_detach().

Comment 6

[Karl Tomlinson (:karlt)]

Thanks, Mike.  That sounds like it, then.

Comment 7

[Karl Tomlinson (:karlt)]

Looks like this may be easier to reproduce when the stack limit is increased to 64MB.

http://groups.google.com/group/mailing.freebsd.current/msg/7602cd24fa065af2

Comment 8

[Mike Melanson]

Reproduced. Thanks for the ulimit stack trick.

Comment 9

[Mike Shaver (:shaver emeritus)]

Mike: any word on when this might be fixed and shipped?

Mozilla folk: how should this be resolved? INVALID? Doesn't seem like it should be an open security bug for us, from my reading.

Comment 10

[Mike Melanson]

It's fixed. I'm not authorized to comment on when the next version will ship.

Comment 11

[Karl Tomlinson (:karlt)]

Thanks, Mike M.

Shaver, I expect the eventual resolution will be INVALID (as with other bugs fixed outside our code).

The advantage of keeping this bug open for now is that it can be found by searches for similar crashes.  INVALID bugs tend not to get searched.  Sometimes crashes involving Flash Player are due to issues in our code and so it's useful to know that this is being fixed elsewhere.  However, that advantage is limited to the security group.

It's not clear to me what the disadvantages are from keeping this bug open until our users with latest updates are no longer affected.  If having this bug open is causing some pain, then it can be resolved INVALID.

Comment 12

[Mike Shaver (:shaver emeritus)]

INVALID bugs are searched by the crash-stats scraper, if they have the correct annotation in the summary.  How will we know to close this?  I think the bug has served its purpose, and that Adobe can be relied upon to test this on whatever the release is that should include the fix referenced in.

Noise in our security bug reports is problematic, because it makes it harder to see the bugs that we should be devoting energy to.

Comment 13

[Karl Tomlinson (:karlt)]

This bug will (at least often) not be found by crash-stats because pthread_detach has a different offset in different versions/configurations of libpthread, so there is an effectively unlimited number of correct annotations.

Comment 14

[timeless]

mike m: if you could indicate the version when a fixed version is released and set the target milestone to the corresponding time interval, that'd be great :).

Comment 15

[BMO Automation]

Version and milestone values are being reset to defaults as part of product refactoring.