Microsoft has published a workaround for a critical bug in the .NET Framework 4.6 that can result in incorrect parameters being passed, with unpredictable results.
Program manager Rich Lander has blogged about the problem.
According to Lander, it can affect any .NET 4.x application, but once the .NET Framework 4.6 has been installed, only those running in 64-bit processes. He adds that most applications will not be affected:
This issue is narrow in nature. Your code has to use specific data types, pass them in specific ways and execute specific operations. Very few programs will satisfy all of these characteristics, which is required to trigger this codegen bug.
We have reviewed this issue to determine if it is exploitable. We have not identified an exploit, but are pushing the change through our process at the same pace as we would an exploit.
We have extensive tests for the .NET Framework libraries (e.g. System.Xml). We have not been able to find a single case of this issue across that very large body of code.
From a production standpoint, big Microsoft web properties have been running on pre-release versions of .NET Framework 4.6 for months without hitting this issue.
Lander said that admins should only apply a workaround if you “run into an issue that you cannot diagnose”, but because of the potential severity of the bug many will prefer a precautionary approach. The workaround is to disable tail call optimization in the new .NET compiler, called RyuJIT, as explained here:
In the registry, create either of the following subkeys:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework
Then, specify the following: Key name: TailCallOpt Type: REG_SZ Value: "0" (Double quotes are not required while entering in the Registry editor)
Another option is to disable the RyuJIT compiler, in which case the older JIT64 compiler is used instead. That is a shame though, since RyuJIT is substantially faster; over 20 times faster in the case of some RegEx expression evaluations.
F# developers should pay special attention. “This issue affects F# programs more commonly,” said Lander, presumably because the nature of the language more often sets up the right conditions for the bug. Lander suggests that F# developers simply do not yet deploy .NET Framework 4.6:
We will post an update on the blog when we are ready to make the all-clear on .NET Framework use for F# developers. We apologize for that situation. We are in the process of increasing our F# test coverage.
Watch this space for updates. ®