| Summary: | Missing initialization of a variable in the CHIL engine (openssl) | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Pavel Raiskup <praiskup> |
| Component: | openssl | Assignee: | Tomas Mraz <tmraz> |
| Status: | CLOSED ERRATA | QA Contact: | BaseOS QE Security Team <qe-baseos-security> |
| Severity: | medium | Docs Contact: | |
| Priority: | high | ||
| Version: | 6.2 | CC: | mvadkert |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | openssl-1.0.0-18.el6 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-12-06 18:08:51 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Bug Depends On: | |||
| Bug Blocks: | 743047 | ||
Actually the problem was always there but Coverity was not able to detect it before the patching. Mirek, is respin still possible due to new deffects found? Note, that we might also need to respin due to the new SSL/TLS attack issue. It is possible if we get exception on the bug. If we will respin becasue of SSL/TLS we should definitely pull this in I think. I'm willing to test it, as a reproducer we could use the coverity scan I assume. Do we actually need an exception? The 1) is just false positive caused by the Coverity static analysis. If you study the code of the fips_set_prng_seed() you'll see that. The 2) is unimportant as it really does not matter what we return in case EVP_DigestInitEx fails. The function does not have any real error return value and moreover the EVP_DigestInitEx can in this case fail only in case of out of memory error or generic crypto engine misconfiguration error. The rest are cosmetic unimportant problems. (In reply to comment #10) > The 1) is just false positive caused by the Coverity static analysis. If you > study the code of the fips_set_prng_seed() you'll see that. > > The 2) is unimportant as it really does not matter what we return in case > EVP_DigestInitEx fails. The function does not have any real error return value > and moreover the EVP_DigestInitEx can in this case fail only in case of out of > memory error or generic crypto engine misconfiguration error. Hi Tomas, thank you that you looked at it.. And I'm sorry for doing the mess here. Anyway, repair of problem from comment 1 is verified by new Coverity run. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2011-1730.html |
=> engines/e_chil.c:1322 Variable 'answer' may be uninitialized when (eg): a) prompt_info == NULL (program does not jump to branch on line 1309 and this variable 'answer' is used on line 1322 when: b) variable 'ok' is greater or equal to 0 Possible solution could be to initialize 'answer' to default value at the beginning of 'if (ui) {}' branch. This problem was newly found in RHEL 6.2 by coverity difference scan on RHEL packages 6.1 → 6.2.