BTW, 65nm Core 2 has errata relating to executing REP SCAS/CMPS with values exceeding 0×100000000. Luckily, it is mentioned that Intel has a microcode update to fix this, which would be essential since it is code generated by a common compiler.

http://www.amazon.com/gp/product/1906717257?ie=UTF8&tag=idebug_in_windbg-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=1906717257

“For all you hardcore hax0rs, Skywing has put together a detailed post on using the AT service and hiew to to inject the updated code into svchost.exe and manually hot patch the running vulnerable service, avoiding a reboot. Fun reading, but not recommended.
In it he claims that he wasn’t able to use BinDiff to identify the patched code, but for those RE’s with a lack of funding, there is a limited trial version of v2.0 that worked great on netapi32 and helped id this problem as a stack overflow within a couple minutes of Microsoft’s patch release. You can see for yourself what a great tool Bindiff really is — google is your friend.”

http://blog.threatfire.com/2008/10/microsoft-is-releasing-out-of-cycle.html

While your proposed remedy accomplishes the goal, I think it worthwhile to point out that the srvsvc pipe is not necessarily required to access the vulnerable function. Because of what appear to be well-known characteristics of Microsoft’s RPC implementation, srvsvc functionality is available over other RPC endpoints registered in-process. This is noteworthy because one endpoint is the BROWSER named pipe, which has a more permissive DACL than than the SRVSVC named pipe. As an example of the practical application of this, see the public Metasploit module that exploits this vulnerability.