From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) by sourceware.org (Postfix) with ESMTPS id 1B81D3858292 for ; Tue, 5 Jul 2022 12:39:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1B81D3858292 Received: by mail-vs1-xe30.google.com with SMTP id q28so11714744vsp.7 for ; Tue, 05 Jul 2022 05:39:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gEWN9/i118wDfxdxujikVbd2UVLnB2+4bnESYO4Xbvg=; b=CbAKLHCgMb8DWvXb/Tsno09sDnLAOA+Fz4OzfhMpEomf/Jye3PeOI29oedTjtj3JzC /ygwiUlmty8Gkjm+7Ax6sCuv9yJpQ5UQaAKDs52r8Yfozu+MjBfA+fuOonGfLpHijZQk NKF7R6UvhXErSxCM6fqTXnZBYwywyRd/Uvxp9mpc5+SFmcnepzx6/iV7L+zAVcWUWz0H 78YEC6to23+1wkWtcCrWXuTcVzcnHWOYtms7ohN0DgQ0cKmEyojTx+uw5jZ/9rwynnW1 YF9h6EjHN96cakisnkWb04DgLRr3BdrBdAzKPM3i1nk0vu8mHSUaGei3BVYxfLGnwqwV ZZhQ== X-Gm-Message-State: AJIora8wFf/jzbKqTXX2ZD/gyXHqFS8eceeZ80dBrvxEo2/1+kbLsn6T XbwGhKjqX+8j2N+ySpuKwyWbOd/nIkm4AiUH X-Google-Smtp-Source: AGRyM1uojK0aY/23d3iQ0NosRT32PKdZRt+rZ6qwFD2HjAxiFIZEAmbn1GM7UyEV5xXC9iVCWp9K0g== X-Received: by 2002:a67:d59b:0:b0:354:2bfa:84af with SMTP id m27-20020a67d59b000000b003542bfa84afmr19070999vsj.12.1657024752447; Tue, 05 Jul 2022 05:39:12 -0700 (PDT) Received: from smtpclient.apple ([2804:431:c7cb:fef6:fc57:dc88:c1a6:22c5]) by smtp.gmail.com with ESMTPSA id y13-20020ac5cf0d000000b0036c07e60a24sm7664087vke.45.2022.07.05.05.39.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Jul 2022 05:39:11 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Subject: Re: Buffer size checking for scanf* functions From: Adhemerval Zanella In-Reply-To: Date: Tue, 5 Jul 2022 09:39:09 -0300 Cc: libc-help@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: <7CD67F72-7AD2-4EC2-9A21-DA4470ACE2F5@linaro.org> References: To: Yair Lenga X-Mailer: Apple Mail (2.3696.100.31) X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE 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-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2022 12:39:15 -0000 > On 5 Jul 2022, at 04:31, Yair Lenga via Libc-help = wrote: >=20 > Hi, >=20 > Looking for feedback on the following age-old scanf problem: I'm = trying to > perform a "safe' scanf, which will avoid buffer overflow. >=20 > #define XSIZE 30 > char x[XSIZE] ; > sscanf(input, "%29s", x) ; You can adjust to use the old stringify macro trick instead: -- $ cat<test.c #include int main (int argc, char *argv[]) { #define XLEN 8 char x[XLEN+1]; #define XSTRINPUT(size) STRINPUT (size) #define STRINPUT(size) "%" #size "s" sscanf (argv[1], XSTRINPUT (XLEN), x); printf ("x=3D%s\n", x); return 0; } EOF $ gcc -Wall test.c -o test $ ./test 1234567890 x=3D12345678 -- It has some limitations where you can=E2=80=99t evaluate neither = arithmetic operations on the macro (for instance XSTRINPTU (XLEN - 1)) nor use compile directives like =E2=80=99sizeof=E2=80=99. >=20 > With the common pitfall that anytime the size of X is changed, the = format > string MUST to be modified. One common approach, with glibc, is to use = the > 'm' modifier, switch x to char **x. However, this require code = changes, and > is not practical with my existing code base. >=20 > My question: is there any extension to allow scanf to take an extra > argument (similar to the scanf_s proposal) - specifying the sizeof any > string arguments ? > sscanf(input, "%S", x, sizeof(x)) ; // The 'S' require adding = sizeof > parameter ? Currently glibc only provides the %m that accepts any input size and you=20= can also use the a maximum field width (something like %128m).=20 >=20 > If there is no such extension - how hard it will be to implement. I = know > possible to define custom conversions for printf, I could not find = anything > for scanf. IF this will be built into 'glibc', there IF it will be = embedded > into the gcc format checks (2 big IFs), it can reduce the problems I = (and I > believe many other developers) face when using those functions. >=20 The glibc does not support hooks for scanf and I don=E2=80=99t think we = will even will, the printf hooks itself has some drawbacks (MT-safeness, etc.). = Also scan_s and similar =E2=80=98enhanced=E2=80=99 functions from TR-24731 = have not been widely=20 implemented mainly because they do not actually improve much. Carlos and Martim, both GNU developers, wrote a paper discussing the problems with these interfaces [1]. In the end scanf family functions are just a really clunky interface = with a lot of pitfalls and I would advice you just rewrite it either avoid = them it or use the =E2=80=98%m=E2=80=99 extension otherwise. [1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm=