From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 4OopDl+u0GrGihAAWB0awg (envelope-from ) for ; Thu, 15 Oct 2026 06:43:43 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=fwydDgRi; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id E88221E050; Thu, 15 Oct 2026 06:43:42 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 30C931E047 for ; Thu, 15 Oct 2026 06:43:40 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1CC904BA2E2A for ; Thu, 15 Oct 2026 10:43:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1CC904BA2E2A Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=fwydDgRi Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 471734BA2E11 for ; Thu, 15 Oct 2026 10:43:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 471734BA2E11 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 471734BA2E11 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1792060985; cv=none; b=X4Sghi6LAKyuXA804ZRaZUS/mXM0+VJm3mTsmUX7HN+EtrNzLaAvYFmExqhybNCB1UJNKxfPZUAa5B9q5RZYpQRJN1Yl0mf7jb6Jx+qaco7l2lrhRTznh4Zc9HVPST6tZGuP0723fAWBQEE0iOTHElVtoSRwUQZT87qQPWAlhJo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1792060985; c=relaxed/simple; bh=CVCexRk6EsigJ9aZH3TO7UNbviOKmA7DGels4enY5A8=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=pa98x+N/aRhuRcq40PSjNBJiRIzBlWtunp4moFQi2FzVzW41R9q0HKoUPyVhLMPBsyJ3vq2VvKeX7AieLhr+CQKG0WSSv4QJf+7xPzUOLSbgTb9igugngafDqoxUSwj0po74yQLhdN+pYPxcJodWJ6NfYULu8N0mpGFoYAAv/5g= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=fwydDgRi DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 471734BA2E11 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1792060984; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qbdVT6yBGMBsHKJ/662vmPaC0weCJpaHKr5OjE3i7sI=; b=fwydDgRiPLTLwDQ9+xpA5ehYC3/te356w8ZDbh2B4+yXXMbpjs3w1rBW1geXAx0KfEAZaD vE+fzIrZJl3hTopuPlbzf08XBPH1ya3u92bMa4iIcB4K/3AZspQcRCQK1ntRmWo1pu5en0 yd+VE6tqLxE3sNM+EMvBGwwtV4oLJpI= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-474-HPgQxr4JOji7Siat-yRoUg-1; Thu, 15 Oct 2026 10:43:02 +0000 X-MC-Unique: HPgQxr4JOji7Siat-yRoUg-1 X-Mimecast-MFC-AGG-ID: HPgQxr4JOji7Siat-yRoUg_1792060982 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-48c4f6f6691so1322092f8f.2 for ; Thu, 15 Oct 2026 03:43:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792060981; x=1792665781; h=content-type:mime-version:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=qbdVT6yBGMBsHKJ/662vmPaC0weCJpaHKr5OjE3i7sI=; b=heMcmEm5mBASeEJCP1qwcRSaQNtvcsp6ok1NFKC4MOPiaQwo75g2hKmcdhFRcYUfVx hdyky5XeTiwkhn2S3CyxTDiCd+b5fGhLcERd4rVBlO9jxXkvc8C6/OkgsikJfQ5SQJiu CjEKg2wIN2+DAH5spGpkdw3Wt/yw+LYXPV9OwtWSFLWzuHBgiE95RwTPhYrltH/qzgXo S5p3jSJrWbygxtcPJ1h0b8s8puJfRWW1EdqbhgnoQK6eFM0u3UNZ7VkzP9vLKZ8ptgW3 gJDwQeqDHe6UmyGVthF0RoW1Z0SEFYZ0Xq9uZYy9FDA1PsrHkg0USVhvd3ls3a+866wb tC0w== X-Forwarded-Encrypted: i=1; AKwUvBw7jVbRWngjr5KQPxxpOib0DOqvbqcu6479ewoeAk+yeToFBMRi5FjoUkEwNvhigVqtvkorD8VO1sViWQ==@sourceware.org X-Gm-Message-State: AFq9FYINAjJ51otMyr3kY8+T2zoJgAB1H84PqBAo3oyumExNF0WfC7ci YfqN7Me6Ew5D98qbiDcExGWX4aP+ukQCtb6D4rHz8g2pnYlApYcLQVLT5ZvGTF5a7GEbU9Zm1ug XtxnulvBZ4S8BBZW1PiG4ww3Xf3lF/VrmTXgtA9yQtWDJRgXOKeTOwd7zwLaaLBM= X-Gm-Gg: AYBFou1tfJYsoSI2szpDeVqojCrLlRoxaO9Dye/EQuGOOZAV0biuRloQNc3Ag1wKXmP eXkY6iRWnsfSuC9eGJPatiGY4/59s6qwY3ojuevRjBvvnew4Sl8e0lFn94N7pWsdv1mDGE7YO4u NAro1i2EzTs3QEOeqsTZK2laa35881bV28vzA8yglgtXsLf9AdBz3RLCzhEPQVlXmpwc3EQfPqh C6hgq0gT2Q72Jd8NY2Xjl8VDzKk8g2hdaLhTHE+GVx2FXqmq318mHnwjDxtulRbQM4bVm7QznKe jG386FD3otWg+IObhsMzPHM3RTL57QmMBbgqcWv0tcPaPmk0dEj/AKUQwrlNHNN4D8BX X-Received: by 2002:a05:6000:468b:b0:48d:f249:82c3 with SMTP id ffacd0b85a97d-48df24984cdmr3196797f8f.30.1792060981370; Thu, 15 Oct 2026 03:43:01 -0700 (PDT) X-Received: by 2002:a05:6000:468b:b0:48d:f249:82c3 with SMTP id ffacd0b85a97d-48df24984cdmr3196778f8f.30.1792060980828; Thu, 15 Oct 2026 03:43:00 -0700 (PDT) Received: from localhost ([213.31.44.29]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48de0aaaa34sm17747992f8f.20.2026.10.15.03.42.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Oct 2026 03:43:00 -0700 (PDT) From: Andrew Burgess To: simon.marchi@polymtl.ca, gdb-patches@sourceware.org Cc: Simon Marchi Subject: Re: [PATCH] gdb: fix out-of-bounds read when printing a pointer with a format In-Reply-To: <20261005024658.927684-1-simon.marchi@polymtl.ca> References: <20261005024658.927684-1-simon.marchi@polymtl.ca> Date: Thu, 15 Oct 2026 11:42:59 +0100 Message-ID: <87zewf8css.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: idXr29nw-YxATwlBzIEeLxETy7zyNnv-K_TpG-qKzqs_1792060982 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org simon.marchi@polymtl.ca writes: > From: Simon Marchi > > I stumbled on this while investigating bug 34638 ("Multi-register-reading > oddity / anachronism"), but this patch is not otherwise related to that > bug. > > When the value being printed is a pointer, print_scalar_formatted > overrides the number of bytes it reads from the value buffer: > > if (type->code () == TYPE_CODE_PTR) > len = gdbarch_addr_bit (gdbarch) / TARGET_CHAR_BIT; > > VALADDR only holds type->length() bytes though, and for a pointer type > built by GDB that is `gdbarch_ptr_bit / TARGET_CHAR_BIT` bytes. On targets > where gdbarch_addr_bit is larger than gdbarch_ptr_bit, we therefore read > past the end of the buffer. > > AVR is such a target: gdbarch_ptr_bit is 16 while gdbarch_addr_bit is 32, > so printing any pointer with a format reads 4 bytes out of a 2-byte buffer. > With a GDB built with AddressSanitizer: > > (gdb) p/x $sp > ================================================================= > ==433709==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7c11d1239e33 at pc 0x55eb8e8438f0 bp 0x7ffc17c69050 sp 0x7ffc17c69040 > > It can be reproduced without running a program, simply with a GDB that has > AVR support, by forcing the architecture to be AVR: > > (gdb) set architecture avr > The target architecture is set to "avr". > (gdb) p/x (void *) 0x1234 > ================================================================= > ==434356==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7bbca0e21293 at pc 0x55f5d74d08f0 bp 0x7ffe74cba960 sp 0x7ffe74cba950 > > "info registers SP" on an AVR target goes through the same path, so hits > the same crash: > > (gdb) c > Continuing. > > Breakpoint 1, main () at test.c:16 > 16 int local = 42; > (gdb) info registers SP > ================================================================= > ==432390==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7b764403b413 at pc 0x55e8ef8628f0 bp 0x7fff13994110 sp 0x7fff13994100 > > The override comes with this comment: > > /* If the value is a pointer, and pointers and addresses are not the > same, then at this point, the value's length (in target bytes) is > gdbarch_addr_bit/TARGET_CHAR_BIT, not type->length (). */ > > This was true when the override was introduced, in commit ef166cf46a1b > (2001). At the time, print_scalar_formatted started by converting the > value to a LONGEST: > > val_long = unpack_long (type, valaddr); > > For pointers, unpack_long goes through extract_typed_address, then > gdbarch_pointer_to_address, which converts the pointer to a CORE_ADDR > gdbarch_addr_bit wide. On AVR, for instance, data pointer 0x1234 (2 bytes > long) becomes address 0x801234 (4 bytes long). "The value" in the comment > refers to this VAL_LONG, not to the bytes at VALADDR. LEN was then only > used to mask VAL_LONG, and the override made sure that the mask did not > truncate the converted address to gdbarch_ptr_bit bits. VALADDR (2 bytes) > was never read using LEN (4 bytes), so there was no out-of-bounds read. > > Commit d9109c8080ac ("Simplify print_scalar_formatted", 2017) changed the > function to print the value using the print_*_chars functions, which > operate directly on the bytes at VALADDR, and removed the conversion to > LONGEST. From then on, the value printed became the raw pointer > representation, type->length() bytes long (2 bytes), not the converted > address (4 bytes). The length override was left in place, and this is > when the out-of-bounds read was introduced. > > Note that commit d9109c8080ac therefore changed how `print (void *) 0x1234` > is printed for architectures like AVR, it went from > > $1 = 0x801234 > > to just > > $1 = 0x1234 > > I don't think it's a mistake in itself, but I am not sure it was fully > understood at the time. > > Since the LEN override no longer has a reason to be, remove it. > > With LEN now always equal to type->length(), the following block becomes > dead code, so remove it. The comment above it is also a relic of the > VAL_LONG time. > > I started by adding a very simple test to > gdb.base/all-architectures.exp.tcl to try to print a formatted pointer with > each arch. I then thought it would be useful to test printing a pointer > without formatting, and then the various kinds of pointers (data vs code). > The result is the somewhat complicated procedure in this patch. It did not > find additional bugs, but I think it's still useful to have in the > testsuite, as it captures what GDB does today. If a change in the pointer > printing code ever changes (notably in the address <-> pointer conversion), > we will notice it. LGTM. Approved-By: Andrew Burgess Thanks, Andrew