A format string attack, at its simplest, is this:

char buffer[128];
gets(buffer);
printf(buffer);

There's a buffer overflow vulnerability in there as well, but the point is this: you're passing untrusted data (from the user) to printf (or one of its cousins) that uses that argument as a format string.

That is: if the user types in "%s", you've got an information-disclosure vulnerability, because printf will treat the user input as a format string, and will attempt to print the next thing on the stack as a string. It's as if your code said printf("%s");. Since you didn't pass any other arguments to printf, it'll display something arbitrary.

If the user types in "%n", you've got a potential elevation of privilege attack (at least a denial of service attack), because the %n format string causes printf to write the number of characters printed so far to the next location on the stack. Since you didn't give it a place to put this value, it'll write to somewhere arbitrary.

This is all bad, and is one reason why you should be extremely careful when using printf and cousins.

What you should do is this:

printf("%s", buffer);

This means that the user's input is never treated as a format string, so you're safe from that particular attack vector.

In Visual C++, you can use the __Format_string annotation to tell it to validate the arguments to printf. %n is disallowed by default. In GCC, you can use __attribute__(__printf__) for the same thing.

There are two high-threat things you can do with format string vulnerabilities in C - leak data and overwrite memory - and neither are relevant in Java. Java's string formatter doesn't even have the "conversion" that is used for overwriting memory, as you noticed. However, Java also is generally safe against such attacks because Java - unlike C - actually checks the number of variadic parameters expected against the number present. If you request a parameter that isn't present - either by index or just by having too many conversions - the formatter will throw an exception. So, there's no way to run off the end of the parameter list and start reading other information from the stack (which is generally not intended to be user-viewable, and may reveal secrets ranging from ASLR masks to cryptographic keys, which could be useful if an attacker can control the format string and invoke the function multiple times).

Interestingly, Java doesn't object if you pass too many variadic parameters - only too few - so you can potentially reveal things that are not normally revealed if the function call is written with excess parameters that aren't usually used. However, that's a pretty unlikely kind of bug, and even then, you could only reveal what those parameters are.

Java's conversions are also type-safe. For example, in C, you can expose pointer values (very valuable when trying to write memory exploits, especially since this can also reveal things like ASLR masks) by asking a format string function to render a pointer (such as to a string) as a numeric type. In Java, that doesn't work; if you pass a string (or any other reference type) and somebody messes with the format string to ask for a hex number, it'll just cause an exception again.

It's worth noting that there is ONE kind of vulnerability possible here: denial of service. An attacker who controls the format string can easily cause the app to throw an exception, for example by supplying the illegal format conversion %0$d (which requests the "zeroeth" parameter as an integer type, when such indices must start at 1). This exception, if uncaught, will cause a crash (even if caught, it may prevent the app from completing its operation correctly). However, as far as I can tell, such denial-of-service risk is the only realistic threat from user-controlled format strings in Java.

The fortify scanner is giving a good catch on this one, reason being user supplied pattern.

Pattern p= Pattern.compile("[0-9]{"+Integer.toString(len-1)+"}"); 

Fortify see the regex pattern constructed based on user input which may result in a DoS. Even so, the resulting pattern on your case at worst will ask the app to capture 2,147,483,646 characters - an enormous number but won't result in catastrophic backtracking. However, you should keep in mind that large enough integer in the quantifier may be rejected by the regex engine.

You could rewrite the code with regex only ensuring the string consist of only integers while length checking done using the good old String.length().

int len = inputString.length();
Pattern p= Pattern.compile("^[0-9]+$");
if(myString.length() == len && p.matcher(myString).find())
{
    //success
}
else
{
    //fail
}

Also, keep in mind there are many ways to broke regex.