Based on work in [1]. According to https://cplusplus.com/reference/cstdio/fprintf/ The use of fprintf is related to the need to generate a string based on a format, which should be different from "%s". Since fprintf has overhead when parsing the "format" parameter, plus all the trouble of checking the va_arg parameters. I think this is one of the low fruits available and easy to reap. By replacing fprintf with its equivalents, fputs and fputc, we avoid overhead and increase security [2] and [3].
The downside is a huge big churm, which unfortunately will occur. But, IHMO, I think the advantages are worth it. Note that behavior remains the same, since fputs and fputc do not change the expected behavior of fprintf. A small performance gain is expected, mainly for the client, since there are several occurrences in some critical places, such as (usr/src/fe_utils/print.c). Patch attached. This pass check-world. regards, Ranier Vilela [1] https://www.postgresql.org/message-id/CAApHDvp2THseLvCc%2BTcYFBC7FKHpHTs1JyYmd2JghtOVhb5WGA%40mail.gmail.com [2] https://stackoverflow.com/questions/20837989/fprintf-stack-buffer-overflow [3] https://bufferoverflows.net/format-string-vulnerability-what-when-and-how/
fprintf_fixes.patch
Description: Binary data
