dmu_redact_snap: Do proper cleanup on ENAMETOOLONG

If the redaction bookmark name exceeds ZFS_MAX_DATASET_NAME_LEN, we
leak the dataset hold, long hold, and decrypt key mapping on the target
snapshot, plus the same three references on each origin snapshot in
args[].

The leaked long holds leave those datasets busy such that destroy,
unmount, and zfs send will return EBUSY and the key mappings never drop.
Using goto out like the other error paths avoids this.

Reported-by: Grok 4.6 Build Beta
Reviewed-by: Brian Behlendorf <[email protected]>
Reviewed-by: Alexander Motin <[email protected]>
Signed-off-by: Richard Yao <[email protected]>
Closes #18962
This commit is contained in:
Richard Yao authored and GitHub committed 2026-08-21 09:56:25 -07:00
1 parent acbcdd92cf
commit df3ff37fc8
1 file changed
+2 -6
+2 -6
View File
@@ -1066,12 +1066,8 @@ dmu_redact_snap(const char *snapname, nvlist_t *redactnvl,
int n = snprintf(c, ZFS_MAX_DATASET_NAME_LEN - (c - newredactbook),
"#%s", redactbook);
if (n >= ZFS_MAX_DATASET_NAME_LEN - (c - newredactbook)) {
dsl_pool_rele(dp, FTAG);
kmem_free(newredactbook,
sizeof (char) * ZFS_MAX_DATASET_NAME_LEN);
if (args != NULL)
vmem_free(args, numsnaps * sizeof (*args));
return (SET_ERROR(ENAMETOOLONG));
err = ENAMETOOLONG;
goto out;
}
err = dsl_bookmark_lookup(dp, newredactbook, NULL, &bookmark);
if (err == 0) {