From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-2.6 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=no autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 1A5E01F461 for ; Sun, 18 Aug 2019 06:11:01 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id A4F5212096B; Sun, 18 Aug 2019 15:10:52 +0900 (JST) Received: from o1678948x4.outbound-mail.sendgrid.net (o1678948x4.outbound-mail.sendgrid.net [167.89.48.4]) by neon.ruby-lang.org (Postfix) with ESMTPS id C19DA120940 for ; Sun, 18 Aug 2019 15:10:49 +0900 (JST) Received: by filter0096p3las1.sendgrid.net with SMTP id filter0096p3las1-9749-5D58EBEC-1 2019-08-18 06:10:52.133297318 +0000 UTC m=+43998.476121109 Received: from herokuapp.com (unknown [52.91.241.246]) by ismtpd0033p1iad2.sendgrid.net (SG) with ESMTP id L5z2ChzcRNiRhUlqWUpesA for ; Sun, 18 Aug 2019 06:10:51.997 +0000 (UTC) Date: Sun, 18 Aug 2019 06:10:52 +0000 (UTC) From: nagachika00@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 69959 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 14834 X-Redmine-Issue-Author: kivikakk X-Redmine-Issue-Assignee: shyouhei X-Redmine-Sender: nagachika X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: =?us-ascii?Q?O2wxg26uOO6cft6GjkEp=2FGevTnH9lR=2FEdG60AX3F8=2FBZ4lD=2FJH9aIGcLYNRIrY?= =?us-ascii?Q?VmKvoJAVqbNjpCH=2F6nrBBEWzveQs5KouywfCq=2Fw?= =?us-ascii?Q?Txxyxga3bLuGThKbqgEvLKH0vTfPj6efMGH8Ucz?= =?us-ascii?Q?CQv+HX+jwtcqly=2FxJeL68LhUbgu9+BLTWC29Gsb?= =?us-ascii?Q?=2FQZnCoX0BLYS9eJH3uE+GeTXP5ujrJ3y+5Q=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 94411 Subject: [ruby-core:94411] [Ruby master Bug#14834] rb_profile_frames SEGV when PC adjusted on IFUNC X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #14834 has been updated by nagachika (Tomoyuki Chikanaga). Backport changed from 2.4: DONTNEED, 2.5: DONTNEED, 2.6: REQUIRED to 2.4: DONTNEED, 2.5: DONTNEED, 2.6: DONE ruby_2_6 r67745 merged revision(s) 5d33f787169bcc3594d2264726695d58c4a06899,8b162ce9d1003e4e469d8f48cb9a2076fd45b47c. ---------------------------------------- Bug #14834: rb_profile_frames SEGV when PC adjusted on IFUNC https://bugs.ruby-lang.org/issues/14834#change-80833 * Author: kivikakk (Ashe Connor) * Status: Closed * Priority: Normal * Assignee: shyouhei (Shyouhei Urabe) * Target version: * ruby -v: ruby 2.6.0dev (2018-06-08 trunk 63606) [x86_64-linux] * Backport: 2.4: DONTNEED, 2.5: DONTNEED, 2.6: DONE ---------------------------------------- Since r62052, we increment `ec->cfp->pc` by one pointer width (e.g. 8 bytes) in `gc_event_hook_body` around the `EXEC_EVENT_HOOK` call. This becomes a problem when the hook is on an IFUNC: in this case, `pc == 0x0`, meaning we increment it to a non-zero value during that call. `rb_profile_frames` uses the following check to determine if frame info should be recorded: ~~~ c if (cfp->iseq && cfp->pc) { ~~~ The example here is [`stackprof`](https://github.com/tmm1/stackprof/blob/58d65ffa801ed27f013d573148783694526c7426/ext/stackprof/stackprof.c#L486), which calls `rb_profile_frames` in a gc event hook. This will segfault currently, as the above check will pass. `calc_lineno` then attempts to calculate the line number: ~~~ c size_t pos = (size_t)(pc - iseq->body->iseq_encoded); ~~~ This fails for a variety of reasons: `iseq_encoded` isn't valid because `iseq` isn't an `rb_iseq_t` underneath, producing an essentially random value, and `pc` is 0x8, so we underflow and eventually cause an overrun in `succ_index_lookup` with a huge `pos` argument. We instead only adjust PC if it appears to be a valid pointer in the first place. ---Files-------------------------------- pc-treatment.diff (777 Bytes) -- https://bugs.ruby-lang.org/