From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 2061 invoked from network); 21 Jun 2023 22:10:55 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 21 Jun 2023 22:10:55 -0000 Received: (qmail 15884 invoked by uid 550); 21 Jun 2023 22:10:52 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 15842 invoked from network); 21 Jun 2023 22:10:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1687385439; x=1689977439; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=3PJczcZm6Z4xhPcGTu1GcBKI13Rt7Qv9Kfj3WqAvDb4=; b=nFt/9wCocZKNVLeWCkZ5E9t3c7IEc88xwmvFurU6OzzmnH2SoUts0L5vzdgbpGjbJJ IXVjwCmYw7myXidaeSxEVfOcmeNXOg23UHpfo+Aj0VbsYS6Ri0p0hMGivxQd6LsrbRJh 2tFjhxmKdPdrBeSVc8TOMVr8y4ON3eGHvXiAVjlyqIOeA1DoVozjx/8xA1CcSc0x4fIf ANmyl0c4iuaF0/RKSACR1eEFNteVTo5JjMPB6sHwtAoNhinshYjimxdV2BQCQ42Q+Kes R04jdJE6Hhi2Ziay+tYN+G2MJrjDEAekX6c/lntuOAawUmkpIdZGheNM+u7Y70wnCtN0 sCxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687385439; x=1689977439; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=3PJczcZm6Z4xhPcGTu1GcBKI13Rt7Qv9Kfj3WqAvDb4=; b=GmG4/yUDQWDrf73QA08xrAjSYIor9PoyGRNULXFicab52fDQ2BgmKJZ5rURBSueaWX lQfntXVEBqsmFnLZzuhHrkhg2q/P+P/Z74/5W5JFbDeEPaTJJKz9LQWdwMfTsoS9XdXt ai7u1OYPJmOQBvqbCXdoNbBcPRWOe1y2UEZThlGtI3x7oN8KyD+fMwhf/4pnyjDRdG0i gOE70sPDqBGm56cnvTjIhbGUlyIoQBMjKIbQOi0euzmMM/W9CC5kHKiN/yKT8Qlh/VkU v4+vIAysea+4lVLDRukPtESM3D/jmmRrMJQCFHHMs7vaWMVpSCLEK3biBBhdZYupKW+D WsIw== X-Gm-Message-State: AC+VfDyov/yYfzAUpdO2XXfRW8pZsp4282uDMZGX8z/3eUPt+6CowIBj E2Z3KUfR2k7I76xYGTgJTiiBYR2PApdGsvOC8HAzbwTGBjkw44yaLLhHzsZ+ X-Google-Smtp-Source: ACHHUZ5bznOTNumeLGVo7K3AegozNeuKTT12uTGj+FfY8eyeti1No61RcfSCKtM2BfayqrF7ES7bTmVie+dchD9l7Cg= X-Received: by 2002:a05:6214:f01:b0:625:87e4:1689 with SMTP id gw1-20020a0562140f0100b0062587e41689mr22308714qvb.20.1687385439179; Wed, 21 Jun 2023 15:10:39 -0700 (PDT) MIME-Version: 1.0 References: <20230621213746.GM4163@brightrain.aerifal.cx> In-Reply-To: <20230621213746.GM4163@brightrain.aerifal.cx> From: enh Date: Wed, 21 Jun 2023 15:10:26 -0700 Message-ID: To: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000b3f1dc05feab09da" Subject: Re: [musl] [PATCH] [RFC] trap on invalid printf formats --000000000000b3f1dc05feab09da Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable i really should do this in bionic... currently we only abort on %n (which is explicitly _not_ supported) or %w with a silly size. for random junk, we currently do what the BSDs do (since that's where this code originally came from): default: /* "%?" prints ?, unless ? is NUL */ if (ch =3D=3D '\0') goto done; /* pretend it was %c with argument ch */ cp =3D buf; *cp =3D ch; size =3D 1; sign =3D '\0'; break; from running a quick test program, macOS and glibc seem to work similarly, which increases the chances that there's incorrect code out there. (clang does at least warn "warning: invalid conversion specifier '?' [-Wformat-invalid-specifier]" by default, though. gcc doesn't.) On Wed, Jun 21, 2023 at 2:38=E2=80=AFPM Rich Felker wrote= : > Inspired by a new instance of some bitrotted software using %Lu > instead of %llu, attached is a draft patch to catch such errors rather > than silently leaving missing output. > > I don't know if this is a good idea to actually do (note: probably > matching changes should be made in wide printf and maybe also scanf if > so) but I'm posting it here in case anyone wants to experiment or > discuss. Note that there is no conformance distinction since invalid > format strings are undefined behavior. > > Rich > --000000000000b3f1dc05feab09da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
i really should do this in bionic... currently we only abo= rt on %n (which is explicitly _not_ supported) or %w with a silly size.
for random junk, we currently do what the BSDs do (since th= at's where this code originally came from):

=C2= =A0 =C2=A0 =C2=A0 default: /* "%?" prints ?, unless ? is NUL */=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (ch =3D=3D '\0') goto done;
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 /* pretend it was %c with argument ch */
=C2=A0= =C2=A0 =C2=A0 =C2=A0 cp =3D buf;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *cp =3D ch= ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 size =3D 1;
=C2=A0 =C2=A0 =C2=A0 =C2=A0= sign =3D '\0';
=C2=A0 =C2=A0 =C2=A0 =C2=A0 break;

from running a quick test program, macOS and glibc se= em to work similarly, which increases the chances that there's incorrec= t code out there. (clang does at least warn "warning: invalid conversi= on specifier '?' [-Wformat-invalid-specifier]" by default, tho= ugh. gcc doesn't.)

On Wed, Jun 21, 2023 at 2:38=E2=80=AFPM Rich = Felker <dalias@libc.org> wrote= :
Inspired by a = new instance of some bitrotted software using %Lu
instead of %llu, attached is a draft patch to catch such errors rather
than silently leaving missing output.

I don't know if this is a good idea to actually do (note: probably
matching changes should be made in wide printf and maybe also scanf if
so) but I'm posting it here in case anyone wants to experiment or
discuss. Note that there is no conformance distinction since invalid
format strings are undefined behavior.

Rich
--000000000000b3f1dc05feab09da--