openssl: A potential NPD bug
In openssl 1.1.0, in the source file engines/e_dasync.c, there is a potential NPD bug.

In Line 757, EVP_aes_128_cbc_hmac_sha1() function may return null, and then is passed to the function call to dasync_cipher_init_key_helper as the fifth parameter. Later, it will be dereferenced in the source file engines/e_dasync.c at Line 638.


Would you help to confirm whether this is a true bug? Thanks.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 23 (17 by maintainers)
Commits related to this issue
- Fix #7950: Prevent NPD dasync cipher helpers when cipher is null. — committed to iamihalcea/openssl by deleted user 5 years ago
- engines/dasync: add explaining comments about AES-128-CBC-HMAC-SHA1 Fixes #7950 It was reported that there might be a null pointer dereference in the implementation of the dasync_aes_128_cbc_hmac_sh... — committed to mspncp/openssl by mspncp 5 years ago
- engines/dasync: add explaining comments about AES-128-CBC-HMAC-SHA1 Fixes #7950 It was reported that there might be a null pointer dereference in the implementation of the dasync_aes_128_cbc_hmac_sh... — committed to openssl/openssl by mspncp 5 years ago
- Fix a NPD bug in engines/e_dasync.c The dasync_aes_128_cbc_hmac_sha1 cipher depends on EVP_aes_128_cbc_hmac_sha1() returning a NON-NULL value. We should simply not advertise this cipher otherwise. F... — committed to bernd-edlinger/openssl by bernd-edlinger 3 years ago
- Fix a NPD bug in engines/e_dasync.c The dasync_aes_128_cbc_hmac_sha1 cipher depends on EVP_aes_128_cbc_hmac_sha1() returning a NON-NULL value. We should simply not advertise this cipher otherwise. F... — committed to openssl/openssl by bernd-edlinger 3 years ago
- 1.1.1n merge (#361) * ASN1: Reset the content dump flag after dumping When encountering a badly coded item, the DER printer (ASN1_print_dump()) sets a flag to ensure that an additional hex dump o... — committed to open-quantum-safe/openssl by baentsch 2 years ago
- Upstream 111p merge (#375) * Add riscv64 target Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14724)... — committed to open-quantum-safe/openssl by baentsch 2 years ago
- upstream 111q merge (#377) * make update (adds a new function code) Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/16027) * Avoid "excessive m... — committed to open-quantum-safe/openssl by baentsch 2 years ago
- Upstream 1.1.1s (#407) * Update copyright year Reviewed-by: Richard Levitte <levitte@openssl.org> * Run make update Reviewed-by: Richard Levitte <levitte@openssl.org> * Prepare for 1.1.1l... — committed to open-quantum-safe/openssl by baentsch 2 years ago
- Upgrade to upstream 1.1.1t (#430) * VMS: Fix misspelt type '__int64', not 'int64_t' Ref: commit 2e5cdbc18a1a26bfc817070a52689886fa0669c2 Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed... — committed to open-quantum-safe/openssl by baentsch a year ago
- Upgrade to upstream 1.1.1t (#430) * VMS: Fix misspelt type '__int64', not 'int64_t' Ref: commit 2e5cdbc18a1a26bfc817070a52689886fa0669c2 Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed... — committed to mamckee/openssl by baentsch a year ago
Actually I don’t think this is a false positive. This test case caues a SEGFAULT when run with OPENSSL_ia32cap=0: