From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14221 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: pengyuanhong Newsgroups: gmane.linux.lib.musl.general Subject: [proposal] Add detection of thread ID in pthread-related interfaces Date: Tue, 11 Jun 2019 11:36:59 +0000 Message-ID: <4CF320752F2B99449115298D4A06B22F34E3DD31@dggemm509-mbx.china.huawei.com> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_4CF320752F2B99449115298D4A06B22F34E3DD31dggemm509mbxchi_" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="175222"; mail-complaints-to="usenet@blaine.gmane.org" Cc: helitao , "Huangqiang (H)" , Jinyongming , leijitang , "liuyutao (C)" , "Liyu (Marvin, Euler Dept)" , "Threefifteen Wang(Kunfeng)" , "Wudilong (Michael)" To: "musl@lists.openwall.com" Original-X-From: musl-return-14237-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jun 11 13:37:26 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1haf5h-000jRx-JI for gllmg-musl@m.gmane.org; Tue, 11 Jun 2019 13:37:25 +0200 Original-Received: (qmail 24556 invoked by uid 550); 11 Jun 2019 11:37:23 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 24522 invoked from network); 11 Jun 2019 11:37:22 -0000 Thread-Topic: [proposal] Add detection of thread ID in pthread-related interfaces Thread-Index: AdUgNlG7C3N+A2ztSByCDuzyqhrlYw== Accept-Language: zh-CN, en-US Content-Language: zh-CN x-originating-ip: [10.133.216.174] X-CFilter-Loop: Reflected Xref: news.gmane.org gmane.linux.lib.musl.general:14221 Archived-At: --_000_4CF320752F2B99449115298D4A06B22F34E3DD31dggemm509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I find that all pthread-related interfaces directly access the input parameter `pthread_t` without any check. If I pass an invalid thread ID (e.g. an exited thread ID) to these interfaces, then segment fault happens. Both glibc and freebsd can do simple detection of thread ID(pthread_t) passed by user and return ESRCH when no thread can be found. They put all threads in a list or hash table, and update this list or table ever= y time a thread is created or exits. >From the user's point of view, segment fault is unbearable and is not * recoverable in most cases. Instead, returning an error of ESRCH * seems more acceptable. --_000_4CF320752F2B99449115298D4A06B22F34E3DD31dggemm509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I find that all pthread-related= interfaces directly access the input

parameter `pthread_t` without a= ny check. If I pass an invalid thread ID

(e.g. an exited thread ID) to t= hese interfaces, then segment fault

happens.

 

Both glibc and freebsd can do s= imple detection of thread ID(pthread_t)

passed by user and return ESRCH= when no thread can be found. They

put all threads in a list or ha= sh table, and update this list or table every

time a thread is created or exi= ts.

 

From the user's point of view, = segment fault is unbearable and is not

·    &nbs= p;    recoverable in most cas= es. Instead, returning an error of ESRCH=

·    &nbs= p;    seems more acceptable.

--_000_4CF320752F2B99449115298D4A06B22F34E3DD31dggemm509mbxchi_--