1718838 - NetBSD: pthread_equal only accepts valid threads

Status: UNCONFIRMED

(NSPR :: NSPR, defect)

Description

[Thomas Klausner]

Attachment: patch-nspr_pr_src_pthreads_ptsynch.c

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:89.0) Gecko/20100101 Firefox/89.0

Steps to reproduce:

pthread_equal on NetBSD only accepts valid thread ids.
nspr calls the function with invalid ones as well, which leads to weird coredumps in firefox.

Actual results:

Run firefox on NetBSD, see coredumps.
There was a whole thread around this on the NetBSD mailing lists some time ago, here's one the mails:
https://mail-index.netbsd.org/source-changes-d/2020/02/03/msg012143.html

Expected results:

Only call pthread_equal on valid thread ids.
A workaround patch that works on NetBSD is attached.
It replaces pthread_equal with a direct comparison.
If the invalid thread ids can be identified some way, we could check for those first and then call pthread_equal.

Comment 1

[Kai Engert [:KaiE:]]

(In reply to Thomas Klausner from comment #0)

nspr calls the function with invalid ones as well, which leads to weird coredumps in firefox.

Wat is the origin of the invalid thread IDs that NSPR uses to call pthread_equal?

Comment 2

[Kai Engert [:KaiE:]]

Comment on attachment 9229491 [details] [diff] [review]
patch-nspr_pr_src_pthreads_ptsynch.c

We cannot do it this way. From the pthread manual:

"The pthread_equal() function is necessary because thread IDs should be considered opaque: there is no portable way for applications to directly compare two pthread_t values."

Comment 3

[Thomas Klausner]

I'm not sure where the invalid thread ids come from.

The backtrace in the referenced email thread ends with:

(gdb) bt
#0 0x000071a59bc0c2eb in pthread_equal () from /usr/lib/libpthread.so.1
#1 0x000071a581e2257b in PR_GetMonitorEntryCount ()
from /usr/pkg/lib/nspr/libnspr4.so
#2 0x000071a58121c595 in SSL3_SendAlert () from /usr/pkg/lib/nss/libssl3.so
#3 0x000071a5812325a2 in ssl_SecureClose () from /usr/pkg/lib/nss/libssl3.so
#4 0x000071a581236910 in ssl_Close () from /usr/pkg/lib/nss/libssl3.so

Do you have an idea how to find out more? I currently don't.

Comment 4

[Kai Engert [:KaiE:]]

Looking through ptsynch.c, it seems all values are taken from pthread_self().

If that results in an invalid pointer, then the bug is caused somewhere else, like a memory corruption.

Comment 5

[Thomas Klausner]

Have you checked if it could be NULL or uninitialized in some code paths?
There are two calls in ptthread.c as well.