"crypto.createCipher()._flush" results in an abort

[zyscoder]

• Version: v14.15.1
• Platform: Linux 5.8.0-38-generic The binary and long term compatibility with node #43~20.04.1-Ubuntu SMP Tue Jan 12 16:39:47 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
• Subsystem: crypto.createCipher

What steps will reproduce the bug?

Setup a node instance,

» node

and run the following javascript code.

crypto.createCipher("aes-256-ccm","",{authTagLength:8})._flush(function(err,data){})

Then an abort occurs.

How often does it reproduce? Is there a required condition?

This abort can always be triggered following the steps above.

What is the expected behavior?

I'm not sure this problem is of crypto or streams, but I still suggest setting these internal APIs as private fields or something like that to prevent misuse. If any error occurs, an exception or other similar error-reporting stuff should be thrown. There is no reason to abort the whole node process.

What do you see instead?

» node
> crypto.createCipher("aes-256-ccm","",{authTagLength:8})._flush(function(err,data){})
node[358058]: ../src/node_crypto.cc:4120:bool node::crypto::CipherBase::Final(node::AllocatedBuffer*): Assertion `(1) == (EVP_CIPHER_CTX_ctrl(ctx_.get(), 0x10, auth_tag_len_, reinterpret_cast<unsigned char*>(auth_tag_)))' failed.
 1: 0xa03530 node::Abort() [node]
 2: 0xa035ae  [node]
 3: 0xb25c04 node::crypto::CipherBase::Final(node::AllocatedBuffer*) [node]
 4: 0xb2e764 node::crypto::CipherBase::Final(v8::FunctionCallbackInfo<v8::Value> const&) [node]
 5: 0xbe369b  [node]
 6: 0xbe4c46  [node]
 7: 0xbe52c6 v8::internal::Builtin_HandleApiCall(int, unsigned long*, v8::internal::Isolate*) [node]
 8: 0x13ff259  [node]
[1]    358058 abort (core dumped)  node

Additional information

[Ayase-252]

As the relevant docs says

This function MUST NOT be called by application code directly. It should be implemented by child classes, and called by the internal Readable class methods only.

Since you are calling Cipher._flush (Cipher extends Transform) directly from application code, it violates precondition and behavior is not guaranteed.

Historically, there is not so-much built-in OOP language features in JavaScript as other language like C++. We could "emulated" private fields by Symbol field in recent practices. But given the importance of stream module, the request to refactor(or semantic changes? considering "access modifier" is never enforced) may be assessed very carefully.

[addaleax]

This is conceptually the same thing as #37884. I'd suggest closing one of them as a duplicate.

[aduh95]

Duplicate of #37884