Bug 1293976
| Summary: | CVE-2015-5229 glibc: calloc() returns non-zero'ed memory [rhel-7.3.0] | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Jeff Layton <jlayton> | ||||||
| Component: | glibc | Assignee: | Carlos O'Donell <codonell> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Arjun Shankar <ashankar> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | high | ||||||||
| Version: | 7.2 | CC: | ashankar, bgollahe, codonell, cww, fweimer, idank, josef, mcermak, mikolaj, mnewsome, pandrade, pfrankli, qe-baseos-tools-bugs, salmy, spoyarek, trond.myklebust, vanhoof | ||||||
| Target Milestone: | rc | Keywords: | Patch, Security, SecurityTracking | ||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | glibc-2.17-107.el7 | Doc Type: | Bug Fix | ||||||
| Doc Text: |
It was discovered that the calloc implementation in glibc could return memory areas which contain non-zero bytes. This could result in unexpected application behavior such as hangs or crashes.
|
Story Points: | --- | ||||||
| Clone Of: | 1246713 | Environment: | |||||||
| Last Closed: | 2016-11-03 08:28:55 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: | |||||||||
| Bug Depends On: | 1246713, 1294080 | ||||||||
| Bug Blocks: | 1256285 | ||||||||
| Attachments: |
|
||||||||
|
Description
Jeff Layton
2015-12-23 21:05:04 UTC
RHEL7 seems to have the same problem as Josef reported here. Attaching a reproducer and a patch that fixes this. Created attachment 1109015 [details]
reproducer for the problem
Reproducer. Build this and watch the asserts pop.
Created attachment 1109016 [details]
patch - malloc: only do the alloc_perturb if the perturb_byte isn't 0
This patch fixes the problem for me.
Note that we have an official support contract as well and have opened a case for this:
https://access.redhat.com/support/cases/#/case/01558997
Oh and to be clear, this is seen in glibc-2.17-106.el7_2.1. ...and appears to be a regression from RHEL7.1 (just by inspection, I haven't actually tested it on RHEL7.1 to confirm it though). *** Bug 1294080 has been marked as a duplicate of this bug. *** This is indeed a regression between rhel-7.1 and rhel-7.2. We dropped one of the fixes that went into rhel-6.7/rhel-6.8 and we should not have, to be specific it was this fix:
commit e8349efd466cfedc0aa98be61d88ca8795c9e565
Author: Ondřej Bílka <neleai>
Date: Mon Dec 9 17:25:19 2013 +0100
Simplify perturb_byte logic.
Which is the correct way to resolve this problem by simplifying the perturbation logic to match upstream (moves the perturb == 0 check into one central place).
We consider this a serious issue and are looking into resolving this as quickly as possible. If you have any questions please don't hesitate to ask. One possible workaround on affected systems may be to set the environment variable MALLOC_PERTURB to 255 to nullify the perturbation effects e.g. 0xff ^ 0xff == 0. This has performance implications though since that additional operation and write have a non-zero cost. Thanks, Yes, commit e8349efd466c seems like a much better fix since you always want to check the perturb_byte value before applying it. We're also aware of the workaround and it does work. We decided instead to just build a glibc package for now with the patch above to use internally until RH releases an official fix. Let us know if you'd like us to test out anything in the meantime. (In reply to Jeff Layton from comment #15) > Thanks, > > Yes, commit e8349efd466c seems like a much better fix since you always want > to check the perturb_byte value before applying it. > > We're also aware of the workaround and it does work. We decided instead to > just build a glibc package for now with the patch above to use internally > until RH releases an official fix. > > Let us know if you'd like us to test out anything in the meantime. Thank you for the feedback Jeff. (In reply to Jeff Layton from comment #2) > Created attachment 1109015 [details] > reproducer for the problem > > Reproducer. Build this and watch the asserts pop. Thanks, I expanded it and committed it upstream: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=1bd5483e104c8bde6e61dc5e3f8a848bc861872d Actually the reproducer was provided by Idan Kedar <idank>...I cc'ed him here (I should have credited him when I uploaded it originally, my bad...) We're at over a month since I first reported this. Any ETA on when the fixed packages will show up in the repo? (In reply to Jeff Layton from comment #20) > We're at over a month since I first reported this. Any ETA on when the fixed > packages will show up in the repo? Do you need immediate fix for this in rhel-7.2.z? Is this a production issue for you? Please talk to GSS if the workaround (set MALLOC_PERTRUB=255) is not working. We plan to fix this for rhel-7.3.0 and rhel-7.2.z. The general availability of RHEL 7.3 is sometime in the future. The release of a rhel-7.2.z is also sometime in the future. I can't give you any specific dates unfortunately. All I can say is that we are releasing a rhel-7.2.z update as soon as we possibly can. I apologize for the delay. 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. https://rhn.redhat.com/errata/RHSA-2016-2573.html |