Repository navigation
"crypto.createCipher()._flush" results in an abort #37922
Description
- 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
Activity
Ayase-252 commentedon Mar 26, 2021
As the relevant docs says
Since you are calling
Cipher._flush(CipherextendsTransform) 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
Symbolfield in recent practices. But given the importance ofstreammodule, the request to refactor(or semantic changes? considering "access modifier" is never enforced) may be assessed very carefully.addaleax commentedon Mar 27, 2021
This is conceptually the same thing as #37884. I'd suggest closing one of them as a duplicate.
aduh95 commentedon Apr 1, 2021
Duplicate of #37884