From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on starla X-Spam-Level: X-Spam-Status: No, score=0.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_BL_SPAMCOP_NET,SPF_HELO_PASS, SPF_PASS autolearn=no autolearn_force=no version=3.4.6 Received: from nue.mailmanlists.eu (nue.mailmanlists.eu [94.130.110.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 3D0871F4CC for ; Wed, 15 Jan 2025 01:53:07 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; unprotected) header.d=ml.ruby-lang.org header.i=@ml.ruby-lang.org header.a=rsa-sha256 header.s=mail header.b=RYa/oQds; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=ruby-lang.org header.i=@ruby-lang.org header.a=rsa-sha256 header.s=s1 header.b=BHQaeCKM; dkim-atps=neutral DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ml.ruby-lang.org; s=mail; t=1736905984; bh=7l9DaTTT8bzhgbJw+ArHG/Qi7V/4fkxIXs0oEUE0hMg=; h=Date:References:To:Reply-To:Subject:List-Id:List-Archive: List-Help:List-Owner:List-Post:List-Subscribe:List-Unsubscribe: From:Cc:From; b=RYa/oQdsENesnShE67HKpvLuYEJ8WzzPivBnfFXARgDKQRsfb0wUP7uYJMXQmSpZW 1yeB3LHJfu8qznquQEV7iQLgtqZq9tgN21mQ8gTB7Q66TAYEjwkA68FQQOCjjk/9sG dYHwmYUBp15FjMprPQ02byEIx6qnGS3rOtpXoLVM= Received: from nue.mailmanlists.eu (localhost [IPv6:::1]) by nue.mailmanlists.eu (Postfix) with ESMTP id 5610646F49 for ; Wed, 15 Jan 2025 01:53:04 +0000 (UTC) Authentication-Results: nue.mailmanlists.eu; dkim=pass (2048-bit key; unprotected) header.d=ruby-lang.org header.i=@ruby-lang.org header.a=rsa-sha256 header.s=s1 header.b=BHQaeCKM; dkim-atps=neutral Received: from s.wrqvwxzv.outbound-mail.sendgrid.net (s.wrqvwxzv.outbound-mail.sendgrid.net [149.72.154.232]) by nue.mailmanlists.eu (Postfix) with ESMTPS id B655346E99 for ; Wed, 15 Jan 2025 01:52:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ruby-lang.org; h=from:references:subject:mime-version:content-type: content-transfer-encoding:list-id:to:cc:content-type:from:subject:to; s=s1; bh=p26HkvnDHYfVqtMHNFv7HI233lStcX36FVC28zU2U6Y=; b=BHQaeCKMKtyz1F2T0HiSIqkdymurmCs7zXLfMyACWcXhJ5mLvEXVahgjTpJcfD3Rn1ty WbBtEp9w/YtaavSHOa7Bt0bAftMRP+AHTAoHzsrsh3oBb5gJLwtVYGXGm78baLJ8D3DVtN 9mdHyijlT90nI7HRvPeBRJKoNhMVgV6Aw3HlAFBZwzFbol2Cj0USb0DwIo7xZ+SkRog7FE 5NAr9QjKaUo5aXLmuDExGpCfMNs7NhCy9w/HHeopcmOSCmQQ6dYGxn6ZZtSKDV/NlwNBy/ +W94nRrUOxC1Mx4xLmyVuLKXFrZnwuS4T5X5nmxqpSnCOm9GxZIpgXuSXwC08Xrw== Received: by recvd-84b546689d-rx8jw with SMTP id recvd-84b546689d-rx8jw-1-678714DA-6 2025-01-15 01:52:26.284355799 +0000 UTC m=+5286678.568804011 Received: from herokuapp.com (unknown) by geopod-ismtpd-36 (SG) with ESMTP id wyQEusH4RiC95b-uBS3Sbg for ; Wed, 15 Jan 2025 01:52:26.215 +0000 (UTC) Date: Wed, 15 Jan 2025 01:52:26 +0000 (UTC) Message-ID: References: Mime-Version: 1.0 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Bug X-Redmine-Issue-Id: 20921 X-Redmine-Issue-Author: peterzhu2118 X-Redmine-Issue-Priority: Normal X-Redmine-Sender: k0kubun 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-Redmine-MailingListIntegration-Message-Ids: 97371 X-SG-EID: =?us-ascii?Q?u001=2EsWSpkbcla4bB6tSlkOwdN01=2FLLwMflJlYDs0Ak3Gg6dwg4YUERnU2ZQsI?= =?us-ascii?Q?KPesnHmuO3R4nEnLV41FQje7rMJs=2FlByQKQxPtJ?= =?us-ascii?Q?4AIt7Pq58gAoTul4D18ZA=2FA=2FYAWvlJFqtucVIJK?= =?us-ascii?Q?70wox52LGcfv6liQVHE7w+aeLgc5bBUvFz6Ekyi?= =?us-ascii?Q?7nyBlfYXl+c8bD8h2y6Igyn6O11zX+Qh2VNxlos?= =?us-ascii?Q?0pZWWAHUewLgJ7XPk4XUyXBCiBev0h8W4+nKALq?= =?us-ascii?Q?nJZS5HsO1jXPPuVRRIY=2F6zRqig=3D=3D?= To: ruby-core@ml.ruby-lang.org X-Entity-ID: u001.I8uzylDtAfgbeCOeLBYDww== Message-ID-Hash: ATLVMHXKAXGHJQWI7Z7Z3J6O3ORNIBXS X-Message-ID-Hash: ATLVMHXKAXGHJQWI7Z7Z3J6O3ORNIBXS X-MailFrom: bounces+313651-b711-ruby-core=ml.ruby-lang.org@em5188.ruby-lang.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9 Precedence: list Reply-To: Ruby developers Subject: [ruby-core:120685] [Ruby master Bug#20921] Use-after-free in constant cache List-Id: Ruby developers Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: "k0kubun (Takashi Kokubun) via ruby-core" Cc: "k0kubun (Takashi Kokubun)" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Issue #20921 has been updated by k0kubun (Takashi Kokubun). Backport changed from 3.1: DONTNEED, 3.2: DONE, 3.3: REQUIRED to 3.1: DONTNEED, 3.2: DONE, 3.3: DONE ruby_3_3 commit:f65a6c090c229de1665af49f2e51fc1d6397ab72. ---------------------------------------- Bug #20921: Use-after-free in constant cache https://bugs.ruby-lang.org/issues/20921#change-111508 * Author: peterzhu2118 (Peter Zhu) * Status: Closed * Backport: 3.1: DONTNEED, 3.2: DONE, 3.3: DONE ---------------------------------------- GitHub PR: https://github.com/ruby/ruby/pull/12203 When we create a cache entry for a constant, the following sequence of events could happen: - vm_track_constant_cache is called to insert a constant cache. - In vm_track_constant_cache, we first look up the ST table for the ID of the constant. Assume the ST table exists because another iseq also holds a cache entry for this ID. - We then insert into this ST table with the iseq_inline_constant_cache. - However, while inserting into this ST table, it allocates memory, which could trigger a GC. Assume that it does trigger a GC. - The GC frees the one and only other iseq that holds a cache entry for this ID. - In remove_from_constant_cache, it will appear that the ST table is now empty because there are no more iseq with cache entries for this ID, so we free the ST table. - We complete GC and continue our st_insert. However, this ST table has been freed so we now have a use-after-free. This issue is very hard to reproduce, because it requires that the GC runs at a very specific time. However, we can make it show up by applying this patch which runs GC right before the st_insert to mimic the st_insert triggering a GC: ```diff diff --git a/vm_insnhelper.c b/vm_insnhelper.c index 3cb23f06f0..a93998136a 100644 --- a/vm_insnhelper.c +++ b/vm_insnhelper.c @@ -6338,6 +6338,10 @@ vm_track_constant_cache(ID id, void *ic) rb_id_table_insert(const_cache, id, (VALUE)ics); } + if (id == rb_intern("MyConstant")) rb_gc(); + st_insert(ics, (st_data_t) ic, (st_data_t) Qtrue); } ``` And if we run this script: ```ruby Object.const_set("MyConstant", "Hello!") my_proc = eval("-> { MyConstant }") my_proc.call my_proc = eval("-> { MyConstant }") my_proc.call ``` We can see that ASAN outputs a use-after-free error: ``` ==36540==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000049528 at pc 0x000102f3ceac bp 0x00016d607a70 sp 0x00016d607a68 READ of size 8 at 0x606000049528 thread T0 #0 0x102f3cea8 in do_hash st.c:321 #1 0x102f3ddd0 in rb_st_insert st.c:1132 #2 0x103140700 in vm_track_constant_cache vm_insnhelper.c:6345 #3 0x1030b91d8 in vm_ic_track_const_chain vm_insnhelper.c:6356 #4 0x1030b8cf8 in rb_vm_opt_getconstant_path vm_insnhelper.c:6424 #5 0x1030bc1e0 in vm_exec_core insns.def:263 #6 0x1030b55fc in rb_vm_exec vm.c:2585 #7 0x1030fe0ac in rb_iseq_eval_main vm.c:2851 #8 0x102a82588 in rb_ec_exec_node eval.c:281 #9 0x102a81fe0 in ruby_run_node eval.c:319 #10 0x1027f3db4 in rb_main main.c:43 #11 0x1027f3bd4 in main main.c:68 #12 0x183900270 () 0x606000049528 is located 8 bytes inside of 56-byte region [0x606000049520,0x606000049558) freed by thread T0 here: #0 0x104174d40 in free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x54d40) #1 0x102ada89c in rb_gc_impl_free default.c:8183 #2 0x102ada7dc in ruby_sized_xfree gc.c:4507 #3 0x102ac4d34 in ruby_xfree gc.c:4518 #4 0x102f3cb34 in rb_st_free_table st.c:663 #5 0x102bd52d8 in remove_from_constant_cache iseq.c:119 #6 0x102bbe2cc in iseq_clear_ic_references iseq.c:153 #7 0x102bbd2a0 in rb_iseq_free iseq.c:166 #8 0x102b32ed0 in rb_imemo_free imemo.c:564 #9 0x102ac4b44 in rb_gc_obj_free gc.c:1407 #10 0x102af4290 in gc_sweep_plane default.c:3546 #11 0x102af3bdc in gc_sweep_page default.c:3634 #12 0x102aeb140 in gc_sweep_step default.c:3906 #13 0x102aeadf0 in gc_sweep_rest default.c:3978 #14 0x102ae4714 in gc_sweep default.c:4155 #15 0x102af8474 in gc_start default.c:6484 #16 0x102afbe30 in garbage_collect default.c:6363 #17 0x102ad37f0 in rb_gc_impl_start default.c:6816 #18 0x102ad3634 in rb_gc gc.c:3624 #19 0x1031406ec in vm_track_constant_cache vm_insnhelper.c:6342 #20 0x1030b91d8 in vm_ic_track_const_chain vm_insnhelper.c:6356 #21 0x1030b8cf8 in rb_vm_opt_getconstant_path vm_insnhelper.c:6424 #22 0x1030bc1e0 in vm_exec_core insns.def:263 #23 0x1030b55fc in rb_vm_exec vm.c:2585 #24 0x1030fe0ac in rb_iseq_eval_main vm.c:2851 #25 0x102a82588 in rb_ec_exec_node eval.c:281 #26 0x102a81fe0 in ruby_run_node eval.c:319 #27 0x1027f3db4 in rb_main main.c:43 #28 0x1027f3bd4 in main main.c:68 #29 0x183900270 () previously allocated by thread T0 here: #0 0x104174c04 in malloc+0x94 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x54c04) #1 0x102ada0ec in rb_gc_impl_malloc default.c:8198 #2 0x102acee44 in ruby_xmalloc gc.c:4438 #3 0x102f3c85c in rb_st_init_table_with_size st.c:571 #4 0x102f3c900 in rb_st_init_table st.c:600 #5 0x102f3c920 in rb_st_init_numtable st.c:608 #6 0x103140698 in vm_track_constant_cache vm_insnhelper.c:6337 #7 0x1030b91d8 in vm_ic_track_const_chain vm_insnhelper.c:6356 #8 0x1030b8cf8 in rb_vm_opt_getconstant_path vm_insnhelper.c:6424 #9 0x1030bc1e0 in vm_exec_core insns.def:263 #10 0x1030b55fc in rb_vm_exec vm.c:2585 #11 0x1030fe0ac in rb_iseq_eval_main vm.c:2851 #12 0x102a82588 in rb_ec_exec_node eval.c:281 #13 0x102a81fe0 in ruby_run_node eval.c:319 #14 0x1027f3db4 in rb_main main.c:43 #15 0x1027f3bd4 in main main.c:68 #16 0x183900270 () ``` This commit fixes this bug by adding a inserting_constant_cache_id field to the VM, which stores the ID that is currently being inserted and, in remove_from_constant_cache, we don't free the ST table for ID equal to this one. -- https://bugs.ruby-lang.org/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/