From patchwork Wed Apr 9 08:26:14 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: dbgbgtf X-Patchwork-Id: 110095 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B8453386549E for ; Wed, 9 Apr 2025 08:27:04 +0000 (GMT) X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) by sourceware.org (Postfix) with ESMTPS id 61E553864821 for ; Wed, 9 Apr 2025 08:26:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 61E553864821 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 61E553864821 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::42c ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1744187198; cv=none; b=InUWCUbJzQmTTcC8tNBBs8awVS+eAmKrh64nThynk0pxMFOm/oPReGjUo2ihcb4ryxptnFwOTzAzpmdbMCnpjn5yKDxeIoNfH/dGVynsmR61ksEBBc5HVmKxor7aQzUXhkpWfKj+eDvKWUDMWRXhPjz40cBNjMl5e+7WVfP0fas= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1744187198; c=relaxed/simple; bh=89HpVqlynvqUKn4FGvqYgDjACDMvxYM+99G/tzx0llE=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=uCcHw+X2OzOsEcSFGu9lwv1j5ZywQ8ykk3UClrOzqoT+3xHVyaC39NHkWM+8LtZHMu2dFVxWG+kD9M/CIMZuqdOLgvfUsNObIPoSPjAWq3GWQl6YUotkWBx/DE4buqyV0zxQ2kOsdnvjWO9LyUQujfoX9P1en/Mxa7ONp/y/bD4= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pf1-x42c.google.com with SMTP id d2e1a72fcca58-73712952e1cso5949840b3a.1 for ; Wed, 09 Apr 2025 01:26:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744187197; x=1744791997; darn=sourceware.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=9AGmU4ftjJRfvIXY28Uh4BkbZZz4l9lFnIsXex600gY=; b=N5mj5ubKId/PSJ/lwJMcNa2Hw2O/aYoqw58fYpbSdSXcY/nt1m0LS/4l5/YHM3pSlU EpWLMUNJN9vsngELTXs8CyBBoarZ6UmEQcegGAY6D5GkAL2cFufTOKS6JuqlfX0TCb5E hxlWiVZGR/D0I/WZUOtDU8cyrtlC1nsSV8f2zjMiMZNB41twYXVDTLct9kW9bQpFD5R5 6RZQp40RLH2HFn4P5a1U0pZzCfIgFtg2NwD4F+0mkPvsQiK6ZGHgIg+ji9a65g77ORsv Gj/H/02z8heyQD0cboKR0d51umRUWoDcznPV1RhVKD6etGzUyLSn5qSYNRcLKJYCILcq 0cCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744187197; x=1744791997; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=9AGmU4ftjJRfvIXY28Uh4BkbZZz4l9lFnIsXex600gY=; b=WpmScTZiu/ph6pV0Cq6lBqQxfSdbRW0730KZ+FndRmL1YT/19C1qGCGUoicXR6QKXq jheMbH446Kf6VbhAVFW06vQvNxPtSMoAQ7GcZYcHQ/g9hncGrNGTAf8ivokKD9rXD8Mf pJz5Cw1WVcDeHYBVG8WnLRI6EVnQZVkKQQQp4vWk82z6J7TOCOWLlgb5Q4FYqWK/hzNY F5VEl9hDpnoQ5UwZmOc2aSdgGShpkcLakxXNJSi8EmKsuvJzHlr8XwYu01r/4RWHXSYc 3YUsiidJiVUKpXvDHTtv7wgo41/Yv3Q2F5KbAPxHxSJ13BrZB7nCe2wUxQLTj0LzZcY0 dMDg== X-Gm-Message-State: AOJu0YyX4sOCr2awkw5Z000lGd952Nb8aSz5iu7jeWKitLjaGMRq+xJt oMYAClHoRuCyQ3ZWiYUEOBWKTXIYMF4EvmK8CL1tVD5iOmmDMI3xp3mLn299u8Q= X-Gm-Gg: ASbGncvMJBwHUi5Rcbt+dCcEj7k9TDYOpijDM67YZsHsOR21HD77R+HGIGxBMQkNbBv e7x9uTFVeOtHPSoyhrTadS4xMwkBze8W5wIMWlhnA71sZ5LOnXtb6bKomCuCM4vll/uPbXnfN+5 GlE2n1uiqAQ6ImAZlA0VithQVbI+7Cx9P+t2c0mv35WHBEU4pWJbpsrlriGhQvfTStqX7ox+Xfg ToKKliDPIv+1CicU2PBflifxkSj2CcKDYz/OO/NkDdcsXOULdA8diHqseN5gZGX84UYUYfx1rvq n9f+PM1pfR+1VOPCf7144sRXgxxxCwwvUXdBBvPV+OWutu3TPThboykAVq2JXey+rQhvdulSu9K ieoOb5A== X-Google-Smtp-Source: AGHT+IFjLR8xWcQbHAnOptghuEpLGCBtkMq9pyztHOaN6Rkbe+YHIaLj2p/oXPrdsYHyA/upc4RBuQ== X-Received: by 2002:a05:6a21:2d09:b0:1f5:8de8:3b1a with SMTP id adf61e73a8af0-2015aea746emr2378009637.13.1744187196723; Wed, 09 Apr 2025 01:26:36 -0700 (PDT) Received: from localhost (61-230-221-107.dynamic-ip.hinet.net. [61.230.221.107]) by smtp.gmail.com with UTF8SMTPSA id d2e1a72fcca58-73bb1d6af07sm716649b3a.79.2025.04.09.01.26.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Apr 2025 01:26:36 -0700 (PDT) From: dbgbgtf X-Google-Original-From: dbgbgtf To: wilco.dijkstra@arm.com Cc: libc-alpha@sourceware.org Subject: [PATCH] malloc: check tcache mem size in tcache_get_n to avoid arbitrary mem allocation Date: Wed, 9 Apr 2025 16:26:14 +0800 Message-ID: <20250409082617.112696-1-dudududuMaxVer@gmail.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: References: MIME-Version: 1.0 X-Spam-Status: No, score=-9.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, HK_RANDOM_ENVFROM, HK_RANDOM_FROM, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libc-alpha-bounces~patchwork=sourceware.org@sourceware.org Hi, > What do you mean with "arb alloc"? Never heard of the term... `arb alloc` is abbreviation of `arbitrary alloc`. > If the malloc succeeds despite corruption, it will likely fail if that block is freed > again, or on the next malloc that uses the now corrupted freelist. Adding free(ptr[0]) > at the end of your test causes "double free or corruption". `ptr[0]` is the address of `ptr[2]` at the end of the test. At this time, attackers already got an arbitrary mem alloc, we shouldn't leave it to `free` or another `malloc`. > You can statically link with GLIBC, but that's not needed here - "make bench" will generate > benchmarks which will always dynamically link with your local GLIBC build. Is that true? Because on my machine ldd shows it will use my system library as default, while the GLIBC build libc.so.6 is in `/home/dbgbgtf/Main/work/build/libc.so.6` ``` ❯ ldd benchtests/bench-malloc-simple linux-vdso.so.1 (0x000077ae74ebf000) libc.so.6 => /usr/lib/libc.so.6 (0x000077ae74c98000) /usr/lib/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x000077ae74ec1000) ``` But anyway, `make bench` will use the correct library to run benchtests. If you're using `make bench`, it's fine. > There is a 3.8% difference between those runs. Which one is old, which one is new? You can tell the old and new ones from the directory, `mybuild` was built with my patch, while `build` was built with the `origin/master`. So you can see my patch is faster, which make me confused. (maybe because I remove the fastbin checks in _int_malloc?) > Note those results seem slow given the i7-13700H is quite new. Are you running on > the fast cores? Does the generated code look well optimized? Those results came from my laptop, so it could be slower than desktop. I didn't specific the tests to use fast cores. But the code is well optimized. So I rerun the benchtests like `taskset -c 0 make bench BENCHSET="malloc-simple"` The result was not different compare to the result in my last email. Also I rerun `make bench BENCHSET="malloc-thread"` This is `origin/master` ``` ❯ cat benchtests/bench-malloc-thread-32.out { "timing_type": "hp_timing", "functions": { "malloc": { "": { "duration": 9.33561e+11, "iterations": 1.10199e+10, "time_per_iteration": 84.7163, "max_rss": 7284, "threads": 32, "min_size": 4, "max_size": 32768, "random_seed": 88 } } } }% ``` This is `origin/master` with my patch ``` ❯ cat benchtests/bench-malloc-thread-32.out { "timing_type": "hp_timing", "functions": { "malloc": { "": { "duration": 9.33958e+11, "iterations": 1.07042e+10, "time_per_iteration": 87.2519, "max_rss": 6820, "threads": 32, "min_size": 4, "max_size": 32768, "random_seed": 88 } } } }% ``` Thanks, dbgbgtf Signed-off-by: dbgbgtf --- malloc/malloc.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/malloc/malloc.c b/malloc/malloc.c index a0bc733482..74f9668d3b 100644 --- a/malloc/malloc.c +++ b/malloc/malloc.c @@ -3186,6 +3186,8 @@ tcache_get_n (size_t tc_idx, tcache_entry **ep) if (__glibc_unlikely (!aligned_OK (e))) malloc_printerr ("malloc(): unaligned tcache chunk detected"); + if (__glibc_unlikely (tc_idx != csize2tidx(chunksize_nomask (mem2chunk(e))))) + malloc_printerr ("malloc(): tcache mem size vs request size"); if (ep == &(tcache->entries[tc_idx])) *ep = REVEAL_PTR (e->next); @@ -4009,11 +4011,6 @@ _int_malloc (mstate av, size_t bytes) while (tcache->counts[tc_idx] < mp_.tcache_count && (tc_victim = *fb) != NULL) { - if (__glibc_unlikely (misaligned_chunk (tc_victim))) - malloc_printerr ("malloc(): unaligned fastbin chunk detected 3"); - size_t victim_tc_idx = csize2tidx (chunksize (tc_victim)); - if (__glibc_unlikely (tc_idx != victim_tc_idx)) - malloc_printerr ("malloc(): chunk size mismatch in fastbin"); if (SINGLE_THREAD_P) *fb = REVEAL_PTR (tc_victim->fd); else