harden: fix use-after-free in zip_crypto_openssl.c (CWE-416)

[anupamme]

The _zip_crypto_aes_free and _zip_crypto_hmac_free functions free memory but do not set the pointer to NULL afterward. In a multi-threaded context or if there's a double-free bug elsewhere, this could lead to use-after-free conditions. The pointer remains dangling after free(), and if accessed again through a race condition, it could cause heap corruption. This is defence-in-depth at TKLiveSync/libzip/zip_crypto_openssl.c:62 rather than a vulnerability I can show is exploitable here — it makes the failure mode explicit and bounded. Close it freely if the pattern is intentional.

Reference: CWE-416

What changed

• TKLiveSync/libzip/zip_crypto_openssl.c

Verification

No automated check could be run against this repository, so this change is unverified beyond review. Please treat it as a suggestion.

---

Automated security fix by OrbisAI Security

[coderabbitai]

Warning

Review limit reached

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Next included review available in 20 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used all 2 included reviews currently available.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

• Configuration used: Repository UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: ed4bf35a-2c59-4358-8be5-6249442047fa

📥 Commits

Reviewing files that changed from the base of the PR and between c5eb963 and 5a387e3.

📒 Files selected for processing (1)

• TKLiveSync/libzip/zip_crypto_openssl.c

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[edusperoni]

Closing. aes = NULL; / hmac = NULL; assign to the function's local parameter copy, so the caller's pointer (e.g. ctx->aes in zip_winzip_aes.c) is unchanged — this is a no-op that the compiler will drop, not a CWE-416 mitigation. Separately, zip_crypto_openssl.c isn't built on iOS at all (libzip/config.h defines HAVE_COMMONCRYPTO).

The PR description itself says the change is unverified. Please don't open auto-generated PRs that haven't been verified against a real, reproducible defect — #429 was a genuine fix and was welcome; this and #440 are not.

[anupamme]

Thanks for the clarification. You’re right on both points.

I missed that aes = NULL / hmac = NULL only updates the local parameter and therefore does not clear the caller’s pointer. More importantly, I didn’t verify that zip_crypto_openssl.c is actually part of the iOS build; with HAVE_COMMONCRYPTO enabled, this finding isn’t applicable to the target platform.

I’ll treat this finding as invalid. I’ll make sure future automated findings are verified for both reachability and platform/build configuration before opening a PR.