Bug 987158

Summary:

strange memory access (possibly red zone related)

Product:

[Fedora] Fedora

Reporter:

Jan Pokorný [poki] <jpokorny>

Component:

openssl

Assignee:

Tomas Mraz <tmraz>

Status:

CLOSED EOL

QA Contact:

Fedora Extras Quality Assurance <extras-qa>

Severity:

unspecified

Docs Contact:

Priority:

unspecified

Version:

CC:

landijk-redhat, tmraz

Target Milestone:

---

Keywords:

Reopened

Target Release:

---

Hardware:

Unspecified

OS:

Unspecified

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2015-06-30 00:40:33 UTC

Type:

Bug

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Attachments:

Description	Flags
Workaround in a form of expect script	none
Workaround expect script (with fixed typo)	none
Workaround expect script (with debug output to stderr rather than stdout)	none

Description Jan Pokorný [poki] 2013-07-22 20:33:59 UTC

This is on x86_64 arch:

$ mkdir /tmp/test && pushd /tmp/test
$ su -
# yum install -y keepalived valgrind
# debuginfo-install keepalived
# exit
$ yes '' | /usr/bin/openssl req -new -x509 -nodes -sha1 -newkey rsa:2048 \
  -keyout cert.pem -out cert.pem
$ openssl s_server -cert cert.pem -key cert.pem -HTTP -tls1 &
$ valgrind --track-origins=yes  genhash -s 127.0.0.1 -S -p 4433 -u '/' \
  >/dev/null
> ==27190== Memcheck, a memory error detector
> ==27190== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
> ==27190== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
> ==27190== Command: genhash -s 127.0.0.1 -S -p 4433 -u /
> ==27190== 
> ==27190== Invalid read of size 4
> ==27190==    at 0x3AC6C0289D: expandNextArg (popt.c:635)
> ==27190==    by 0x3AC6C036B5: poptGetNextOpt (popt.c:929)
> ==27190==    by 0x401EAC: main (main.c:101)
> ==27190==  Address 0x4e93ec8 is 8 bytes inside a block of size 10 alloc'd
> ==27190==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
> ==27190==    by 0x3AC6C0279E: expandNextArg (popt.c:602)
> ==27190==    by 0x3AC6C036B5: poptGetNextOpt (popt.c:929)
> ==27190==    by 0x401EAC: main (main.c:101)
> ==27190== 
> ==27190== Invalid read of size 4
> ==27190==    at 0x3AC6C02888: expandNextArg (popt.c:635)
> ==27190==    by 0x3AC6C036B5: poptGetNextOpt (popt.c:929)
> ==27190==    by 0x401EF6: main (main.c:135)
> ==27190==  Address 0x4e940a4 is 4 bytes inside a block of size 5 alloc'd
> ==27190==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
> ==27190==    by 0x3AC6C0279E: expandNextArg (popt.c:602)
> ==27190==    by 0x3AC6C036B5: poptGetNextOpt (popt.c:929)
> ==27190==    by 0x401EF6: main (main.c:135)
> ==27190== 
> ==27190== Conditional jump or move depends on uninitialised value(s)
> ==27190==    at 0x3AC2C32998: tls1_enc (t1_enc.c:832)
> ==27190==    by 0x3AC2C29919: ssl3_read_bytes (s3_pkt.c:402)
> ==27190==    by 0x3AC2C26D11: ssl3_read_internal (s3_lib.c:4207)
> ==27190==    by 0x4067B2: ssl_read_thread (ssl.c:167)
> ==27190==    by 0x402099: main (main.c:221)
> ==27190==  Uninitialised value was created by a stack allocation
> ==27190==    at 0x3AC04883B7: aesni_cbc_encrypt (aesni-x86_64.s:2081)
> ==27190== 
> ==27190== Conditional jump or move depends on uninitialised value(s)
> ==27190==    at 0x405104: extract_html (html.c:89)
> ==27190==    by 0x405FB9: http_process_stream (http.c:136)
> ==27190==    by 0x4067D8: ssl_read_thread (ssl.c:180)
> ==27190==    by 0x402099: main (main.c:221)
> ==27190==  Uninitialised value was created by a stack allocation
> ==27190==    at 0x3AC04883B7: aesni_cbc_encrypt (aesni-x86_64.s:2081)
> ==27190== 
> ==27190== Use of uninitialised value of size 8
> ==27190==    at 0x3AAE4468B1: _itoa_word (_itoa.c:180)
> ==27190==    by 0x3AAE447826: vfprintf (vfprintf.c:1614)
> ==27190==    by 0x3AAE5080F0: __printf_chk (printf_chk.c:36)
> ==27190==    by 0x405E9F: finalize (stdio2.h:104)
> ==27190==    by 0x402099: main (main.c:221)
> ==27190==  Uninitialised value was created by a stack allocation
> ==27190==    at 0x3AC04883B7: aesni_cbc_encrypt (aesni-x86_64.s:2081)
> ==27190== 
> ==27190== Conditional jump or move depends on uninitialised value(s)
> ==27190==    at 0x3AAE4468B8: _itoa_word (_itoa.c:180)
> ==27190==    by 0x3AAE447826: vfprintf (vfprintf.c:1614)
> ==27190==    by 0x3AAE5080F0: __printf_chk (printf_chk.c:36)
> ==27190==    by 0x405E9F: finalize (stdio2.h:104)
> ==27190==    by 0x402099: main (main.c:221)
> ==27190==  Uninitialised value was created by a stack allocation
> ==27190==    at 0x3AC04883B7: aesni_cbc_encrypt (aesni-x86_64.s:2081)
> ==27190== 
> ==27190== Conditional jump or move depends on uninitialised value(s)
> ==27190==    at 0x3AAE44787D: vfprintf (vfprintf.c:1614)
> ==27190==    by 0x3AAE5080F0: __printf_chk (printf_chk.c:36)
> ==27190==    by 0x405E9F: finalize (stdio2.h:104)
> ==27190==    by 0x402099: main (main.c:221)
> ==27190==  Uninitialised value was created by a stack allocation
> ==27190==    at 0x3AC04883B7: aesni_cbc_encrypt (aesni-x86_64.s:2081)
> ==27190== 
> ==27190== Conditional jump or move depends on uninitialised value(s)
> ==27190==    at 0x3AAE44743A: vfprintf (vfprintf.c:1614)
> ==27190==    by 0x3AAE5080F0: __printf_chk (printf_chk.c:36)
> ==27190==    by 0x405E9F: finalize (stdio2.h:104)
> ==27190==    by 0x402099: main (main.c:221)
> ==27190==  Uninitialised value was created by a stack allocation
> ==27190==    at 0x3AC04883B7: aesni_cbc_encrypt (aesni-x86_64.s:2081)
> ==27190== 
> ==27190== Conditional jump or move depends on uninitialised value(s)
> ==27190==    at 0x3AAE4474B9: vfprintf (vfprintf.c:1614)
> ==27190==    by 0x3AAE5080F0: __printf_chk (printf_chk.c:36)
> ==27190==    by 0x405E9F: finalize (stdio2.h:104)
> ==27190==    by 0x402099: main (main.c:221)
> ==27190==  Uninitialised value was created by a stack allocation
> ==27190==    at 0x3AC04883B7: aesni_cbc_encrypt (aesni-x86_64.s:2081)
> ==27190== 
> ==27190== 
> ==27190== HEAP SUMMARY:
> ==27190==     in use at exit: 83,424 bytes in 2,687 blocks
> ==27190==   total heap usage: 3,595 allocs, 908 frees, 284,531 bytes allocated
> ==27190== 
> ==27190== LEAK SUMMARY:
> ==27190==    definitely lost: 19 bytes in 4 blocks
> ==27190==    indirectly lost: 0 bytes in 0 blocks
> ==27190==      possibly lost: 349 bytes in 18 blocks
> ==27190==    still reachable: 83,056 bytes in 2,665 blocks
> ==27190==         suppressed: 0 bytes in 0 blocks
> ==27190== Rerun with --leak-check=full to see details of leaked memory
> ==27190== 
> ==27190== For counts of detected and suppressed errors, rerun with: -v
> ==27190== ERROR SUMMARY: 116 errors from 9 contexts (suppressed: 2 from 2)
$ kill $!
$ popd


What I am asking for is to get rid of these spurious warnings conntected
with:
> ==27190==  Uninitialised value was created by a stack allocation
> ==27190==    at 0x3AC04883B7: aesni_cbc_encrypt (aesni-x86_64.s:2081)
(most of them in the output) as they make going haunting real issues
harder.

Indeed, provided that they are spurious, but [1] leads me to think so.
Also it seems it should be already fixed upstream?

Note that the scenario required to run s_server with -tls1 so as to
trigger this behavior.  (There can be more conditions, but -tls1 worked
reliably for me).


$ rpm -q openssl keepalived
openssl-1.0.1e-4.fc18.x86_64
keepalived-1.2.7-3.fc18.x86_64


[1] https://rt.openssl.org/Ticket/Display.html?id=2862

Comment 1 Jan Pokorný [poki] 2013-07-22 20:34:54 UTC

valgrind-3.8.1-9.fc18.x86_64

Comment 2 Tomas Mraz 2013-07-23 07:42:08 UTC

Yes, the accesses to the red zone (which are valid and not error) are causing this.
Quoting from the upstream ticket: "You can disable AES-NI code by setting OPENSSL_ia32cap environment variable to ~0x200000000000000."

The warnings are triggered by -tls1 probably because of choice of different algorithms for the encryption. AES has to be used for this to be triggered.

The upstream changed this in unreleased development branches and given the workaround above that you can use during debugging I don't really see the need to backport the change.

Comment 3 Jan Pokorný [poki] 2013-07-23 13:25:50 UTC

The only reason I've reported this because I thought Fedora aims to be
developers-friendly.  Should rethink it.

Comment 4 Tomas Mraz 2013-07-23 13:34:02 UTC

That makes sense and I can put this to list of work on rawhide.

Comment 5 Jan Pokorný [poki] 2013-07-23 18:00:42 UTC

Created attachment 777404 [details]
Workaround in a form of expect script

Tomáši, thanks for considering it for future.

Until then, I've put together a workaround (hopefully) minimizing
manual work needed to get the offending occurrences suppressed
in valgrind.  Maybe it will be helpful for anyone else (but I am
not going to support it in any way).

Alternative is to extend default.supp distributed with valgrind but
this is more like a thin ice.

FWIW, from my tests and (limited) understanding of valgrind, neither
--core-redzone-size nor --redzone-size helped (tried various values
ranging from 0 to 256).  So the attached script probably offers most
convenient currently achievable solution.

Comment 6 Jan Pokorný [poki] 2013-07-23 18:03:54 UTC

Created attachment 777411 [details]
Workaround expect script (with fixed typo)

Comment 7 Jan Pokorný [poki] 2013-07-23 19:24:46 UTC

Created attachment 777435 [details]
Workaround expect script (with debug output to stderr rather than stdout)

Comment 8 landijk-redhat 2013-09-12 17:15:19 UTC

Does the --workaround-gcc296-bugs option in valgrind suppress the errors?

Comment 9 Jan Pokorný [poki] 2013-09-12 18:32:09 UTC

Landijk, tried adding --workaround-gcc296-bugs=yes as a first option to
valgrind in the mentioned reproducer and it had _no effect_, AFAICT.
Definitely, aesni_cbc_encrypt stack allocation is still being mentioned.

Comment 10 Fedora End Of Life 2013-09-16 16:48:35 UTC

This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle.
Changing version to '20'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20

Comment 11 Fedora End Of Life 2015-05-29 09:12:48 UTC

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 12 Fedora End Of Life 2015-06-30 00:40:33 UTC

Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.