Stack blowout in _w95_dump_dke

[Andreas Mohr]

Hi,

On Mon, Jul 12, 2004 at 07:53:33AM +1000, by way of Troy Rollo <troy at corvu.com.au> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> _w95_dump_dke has code in it that processes sibling keys in the registry
> recursively. This results in a stack blowout for large registries (in my case
> in the Software\CLASSES key).
Ah, someone else also discovered it.
Yep, also Software\CLASSES.

> It's trivial to stop the stack blowing out by changing this not to be
> recursive, but processing siblings recursively is such an unusual thing to do
> that I suspect it must have been done for a reason. Attached is the way I've
> "fixed" it, but this causes the keys to be output in the opposite order to
> the way they are output with the CVS code.
Same here. I intended to fix it, but at the same time I suspected that there
is a reason for this to be done recursively.

> Is there a reason this needs to be done in the order the CVS code is doing
>  it?
- entry sort order?
- coolness? ;) (ok, forget it, it's not cool...)

This came up on LinuxTag, and we asked Marcus Meissner (who also visited
us there :) about some specifics, but of course he doesn't remember much
after almost a decade ;-)
I think what one should do is testing it with a *small* Win9x registry
(well, at least small enough to not crash...) and comparing the result with
recursive and non-recursive code.

The beginning of that function also does some suspicious root key check
which isn't particularly helpful for recursive call performance...
(would be useful to get that re-coded away somehow when going for a more
iterative approach).

How to proceed?
Anyway, this cries for a fix, since probably many Win9x installations are
affected.

Greetings,

Andreas Mohr