remove %n support from printf(9)

[emaste]

Summary

It can be dangerous and there is no need for it in the kernel. Inspired by Kees Cook's change in Linux, and later OpenBSD.

[gordon]

Have we checked to see how often this is used in tree?

[emaste]

In D24760#545153, @gordon wrote:

Have we checked to see how often this is used in tree?

It's not. grepping sys turns up a couple of sscanfs and a bunch of unrelated %ns.

[philip]

I double-checked @emaste's grep and likewise see no consumer of %n in callers of kernel printf(9).

[gordon]

Looks good to me. I haven't tested it, but seeing as it is the same patch as OpenBSD's it should do what is expected.

[imp]

Can we hack clang to warn? Or enable a clang option?

[imp]

Or noisily complain / panic?

[cem]

In D24760#545321, @imp wrote:

Or noisily complain / panic?

I think this should do it:

--- a/contrib/llvm-project/clang/lib/AST/PrintfFormatString.cpp
+++ b/contrib/llvm-project/clang/lib/AST/PrintfFormatString.cpp
@@ -316,8 +316,8 @@ static PrintfSpecifierResult ParsePrintfSpecifier(FormatStringHandler &H,
     case 'g': k = ConversionSpecifier::gArg; break;
     case 'i': k = ConversionSpecifier::iArg; break;
     case 'n':
-      // Not handled, but reserved in OpenCL.
-      if (!LO.OpenCL)
+      // Not handled, but reserved in OpenCL and FreeBSD kernel.
+      if (!LO.OpenCL && !isFreeBSDKPrintf)
         k = ConversionSpecifier::nArg;
       break;
     case 'o': k = ConversionSpecifier::oArg; break;

[imp]

Thanks cem