fix: use proper return value check for EVP_CIPHER_CTX_ctrl()

[ndossche]

This function can theoretically return -1, which would then be converted to a truthy value. If this happens, then this can cause issues at the use sites. E.g. for the test-crypto-cipheriv-decipheriv test in Node this can cause a buffer overflow when we test with an injected error:

==714700==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x502000032b98 at pc 0x558a7790bb98 bp 0x7ffdcdd5ab10 sp 0x7ffdcdd5a2c8
READ of size 12 at 0x502000032b98 thread T0
    #0 0x558a7790bb97 in memcpy (/work/node/out/Debug/node+0x1b0bb97) (BuildId: adb5b2c9018fdb0733966a1a971077d03aca6d5f)
    #1 0x7efe5386f90b  (/lib/x86_64-linux-gnu/libcrypto.so.3+0x45f90b) (BuildId: aa3dafdd9b54db25d7c9f5335b73ca5fcb293b7f)
    #2 0x7efe536312c2 in EVP_CipherInit_ex (/lib/x86_64-linux-gnu/libcrypto.so.3+0x2212c2) (BuildId: aa3dafdd9b54db25d7c9f5335b73ca5fcb293b7f)
    #3 0x558a7d3e7785 in ncrypto::CipherCtxPointer::init(ncrypto::Cipher const&, bool, unsigned char const*, unsigned char const*) /work/node/out/../deps/ncrypto/ncrypto.cc:3328:10
    #4 0x558a78512a1b in node::crypto::CipherBase::CommonInit(char const*, ncrypto::Cipher const&, unsigned char const*, int, unsigned char const*, int, unsigned int) /work/node/out/../src/crypto/crypto_cipher.cc:366:13
    #5 0x558a785125dd in node::crypto::CipherBase::InitIv(char const*, node::crypto::ByteSource const&, node::crypto::ArrayBufferOrViewContents<unsigned char> const&, unsigned int) /work/node/out/../src/crypto/crypto_cipher.cc:409:3
    #6 0x558a7850f5f4 in node::crypto::CipherBase::New(v8::FunctionCallbackInfo<v8::Value> const&) /work/node/out/../src/crypto/crypto_cipher.cc:328:11
    #7 0x558a788ee605 in v8::internal::FunctionCallbackArguments::CallOrConstruct(v8::internal::Tagged<v8::internal::FunctionTemplateInfo>, bool) /work/node/out/../deps/v8/src/api/api-arguments-inl.h:93:3
    #8 0x558a788ec3ba in v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<true>(v8::internal::Isolate*, v8::internal::DirectHandle<v8::internal::HeapObject>, v8::internal::DirectHandle<v8::internal::FunctionTemplateInfo>, v8::internal::DirectHandle<v8::internal::Object>, unsigned long*, int) /work/node/out/../deps/v8/src/builtins/builtins-api.cc:104:16
    #9 0x558a788e91fc in v8::internal::Builtin_Impl_HandleApiConstruct(v8::internal::BuiltinArguments, v8::internal::Isolate*) /work/node/out/../deps/v8/src/builtins/builtins-api.cc:135:3
    #10 0x558a788e91fc in v8::internal::Builtin_HandleApiConstruct(int, unsigned long*, v8::internal::Isolate*) /work/node/out/../deps/v8/src/builtins/builtins-api.cc:126:1
    #11 0x7efe31a951b5  (<unknown module>)

Note: this was found by a static-dynamic analyser I'm developing.

[jasnell]

LGTM but this needs lint fixups before it can land.

[ndossche]

Right, the problem is the asan output that's longer than the max line length. Do you have a preference how to solve this?

[jasnell]

... Do you have a preference how to solve this?

Um.. the lint issues are pretty straight forward. Just fix them?

[ndossche]

... Do you have a preference how to solve this?

Um.. the lint issues are pretty straight forward. Just fix them?

No, the commit message one isn't really. I just shortened the ASAN output a bit so that succeeds now.
But I suppose you were referring to the clang format linter. That one failed because the docker container didn't start properly the first time in CI, so I didn't see the messages there. So I didn't think you referred to that.
Anyway, I ran clang format too now.