From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-relay-internal-0.canonical.com (smtp-relay-internal-0.canonical.com [185.125.188.122]) by sourceware.org (Postfix) with ESMTPS id BD98B3858D33 for ; Tue, 14 Mar 2023 19:47:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BD98B3858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=canonical.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=canonical.com Received: from mail-pf1-f200.google.com (mail-pf1-f200.google.com [209.85.210.200]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-0.canonical.com (Postfix) with ESMTPS id 6738A3F1C3 for ; Tue, 14 Mar 2023 19:47:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1678823256; bh=v2yemJZAwYqMNQsQAvVw98XgJt4bFIJ3Q1FnXCxk4nk=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=OLXaMAynOWx5oC4nDzIHb5upXSBcrx/OIRbIHCaVWHDDKjz/+8+MF1ticXkQPocPu eAtBWxVOmseZRqcd2C389i7Al+wZEsmTwsFIpjRQYvDyxmX2q7w6MfuPFCC+AbEfDR R5IWAEd029biamMAm1am+z4si7Q20Efoc+2MsH2EusHcUJSwuACB0Dgy0zydlZYu4M HJ8Dpl2QdAmSNf9N990xxi22dnzCwmjx54hRJMruL+OxMuEwIiN36gPPbG33kHVst/ D5QGto8sQH1NpClsw+LFyg9jqJWfyuKRT29RhCAT0yPXqTK5nhOA73kXIXKdK/SPKS CQY7ezQBhYVcA== Received: by mail-pf1-f200.google.com with SMTP id bx9-20020a056a00428900b005f077bc6e5eso8902735pfb.16 for ; Tue, 14 Mar 2023 12:47:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678823255; h=to:subject:message-id:date:user-agent:from:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=v2yemJZAwYqMNQsQAvVw98XgJt4bFIJ3Q1FnXCxk4nk=; b=k6WSRjsJjJCXRgBwBXiSDVfZq40bW6WImV7zZRawt1WI2QYA+wxXbYzc0m1AmjbhIg n56Yl8kgCFS/hFfKDl1u22VU6vq3SI0F2QSrrr6Qcb4RO+MZu32l2xGraU2hlVYqMeBk Jp2i3MLKEp3+5lhWaSmTPyB9AP1EaNGwgH9GRrAhtecRUfM6C8i+r057m53T2MEBRMLz Y+0IhfH1mlA5zPNgncIUAPzzVmVb3E0hA46KlxZlfe9LFre0tq1fHrhKydUNkI+0mpVX bPmLCIAix6RcALqetHdMb2E7E6fyJZee+j9DE2TF64LNhX6pgBdaWz7BJ/WP0QFuIeXD M5OA== X-Gm-Message-State: AO0yUKWK5gw6YaMYBpsXNvDZ0U8rXAck8/FsmyhzloBlrRKV7/43p5X8 OBPh0Km15z/9b3+5FnKbs5B2rPnj/NertCQSY0u8vryGG/11zsVQYW0+CSvvo4+aTv7Jw/PYVmk zYGwffUtslkmOO6PCQ8MDkSSBy8ryjpefU+FEjBBOOvfi5Nx624zTHR82sAB9UQ== X-Received: by 2002:a63:ee12:0:b0:503:77cd:8748 with SMTP id e18-20020a63ee12000000b0050377cd8748mr13026941pgi.8.1678823254886; Tue, 14 Mar 2023 12:47:34 -0700 (PDT) X-Google-Smtp-Source: AK7set9YAoviU4u/yrD4hwWWPG8eQmZZXk/YEmSIGtC0fvFn0+GOCIWURs1uGoINy6eCQ8MWz0235j40CQsNTBQr5Nc= X-Received: by 2002:a63:ee12:0:b0:503:77cd:8748 with SMTP id e18-20020a63ee12000000b0050377cd8748mr13026935pgi.8.1678823254420; Tue, 14 Mar 2023 12:47:34 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Tue, 14 Mar 2023 15:47:33 -0400 MIME-Version: 1.0 From: Simon Chopin User-Agent: alot/0.10 Date: Tue, 14 Mar 2023 15:47:33 -0400 Message-ID: Subject: UB status of snprintf on invalid ptr+size combination? To: libc-alpha@sourceware.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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 List-Id: Hi, We've come across a couple of regressions[0] in 2.37 on armhf due to a peculiar use of snprintf that boils down to this: char [32]buf; ... snprintf(buf, INT_MAX, "%s", "Hello world"); This used to work fine, but now fails in a non-obvious way: the return value is the one you would expect from a successful call (here, 11), but the last character is overwritten by a NUL terminator. It's likely the new behavior has been introduced by commit e88b9f0e5cc50cab57a299dc7efe1a4eb385161d Author: Florian Weimer Date: Mon Dec 19 18:56:54 2022 +0100 stdio-common: Convert vfprintf and related functions to buffers We're hitting the issue because buf+INT_MAX overflows on armhf (being 32-bit and on the stack). When the issue was first discovered[1], I didn't raise the issue because I dismissed it as UB, but it reappeared in an unrelated context, and colleagues pointed out that the wording in the standard doesn't actually say that the `n` argument is the size of the array. Do you think it worth it to try and fix this regression? Florian suggested an approach similar to commit 0d50f477f47ba637b54fb03ac48d769ec4543e8d Author: Florian Weimer Date: Wed Jan 25 08:01:00 2023 +0100 stdio-common: Handle -1 buffer size in __sprintf_chk & co (bug 30039) Thanks in advance, Simon [0]: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/2011326 [1]: https://bugs.launchpad.net/ubuntu/+source/notcurses/+bug/2008108 -- Simon Chopin Foundations Team Ubuntu MOTU/Core Dev simon.chopin@canonical.com schopin@ubuntu.com