find_subkey() can crash when accessing a deleted subkey. When a key is deleted, its node may remain in the subkeys array but key->obj.name becomes NULL due to unlink_named_object(). This can happen when iterating over subkeys during rename or delete operations.
Signed-off-by: chenzhengyong chenzhengyong@uniontech.com
From: chenzhengyong chenzhengyong@uniontech.com
find_subkey() can crash when accessing a deleted subkey. When a key is deleted, its node may remain in the subkeys array but key->obj.name becomes NULL due to unlink_named_object(). This can happen when iterating over subkeys during rename or delete operations.
Signed-off-by: chenzhengyong chenzhengyong@uniontech.com --- server/registry.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/server/registry.c b/server/registry.c index 7cfefc7a6c3..954aaf712f4 100644 --- a/server/registry.c +++ b/server/registry.c @@ -297,6 +297,8 @@ static struct key *find_subkey( const struct key *key, const struct unicode_str while (min <= max) { i = (min + max) / 2; + if (key->subkeys[i]->flags & KEY_DELETED) + break; len = min( key->subkeys[i]->obj.name->len, name->len ); res = memicmp_strW( key->subkeys[i]->obj.name->name, name->str, len ); if (!res) res = key->subkeys[i]->obj.name->len - name->len;
Add a check for KEY_DELETED to skip deleted subkeys. A more robust fix might be to use a linear scan instead of binary search, but that could affect performance.
Could you add a test for this?
On Thu Oct 23 01:55:11 2025 +0000, Nikolay Sivov wrote:
Could you add a test for this?
Sure, no problem — I’ll add a test for this shortly.
-
chenzhengyong -
Nikolay Sivov (＠nsivov)
-
zhengyong chen (＠chenzhengyong)