CVE-2015-5229
published 2016-04-08CVE-2015-5229: The calloc function in the glibc package in Red Hat Enterprise Linux (RHEL) 6.7 and 7.2 does not properly initialize memory areas, which might allow…
PriorityP432high7.5CVSS 3.0
AVNACLPRNUINSUCNINAH
EPSS
2.24%
82.7th percentile
The calloc function in the glibc package in Red Hat Enterprise Linux (RHEL) 6.7 and 7.2 does not properly initialize memory areas, which might allow context-dependent attackers to cause a denial of service (hang or crash) via unspecified vectors.
Affected
10 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | glibc | — | — |
| redhat | enterprise_linux | — | — |
| redhat | enterprise_linux | — | — |
| redhat | enterprise_linux_desktop | — | — |
| redhat | enterprise_linux_hpc_node | — | — |
| redhat | enterprise_linux_hpc_node_eus | — | — |
| redhat | enterprise_linux_server | — | — |
| redhat | enterprise_linux_server_aus | — | — |
| redhat | enterprise_linux_server_eus | — | — |
| redhat | enterprise_linux_workstation | — | — |
CVSS provenance
nvdv3.07.5HIGHCVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
nvdv2.05.0MEDIUMAV:N/AC:L/Au:N/C:N/I:N/A:P
vendor_debian7.5LOW
vendor_redhat7.5HIGH
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
GHSA
GHSA-vhfq-hmc6-hfjh: The calloc function in the glibc package in Red Hat Enterprise Linux (RHEL) 6
ghsa_unreviewed·2022-05-17
CVE-2015-5229 [HIGH] GHSA-vhfq-hmc6-hfjh: The calloc function in the glibc package in Red Hat Enterprise Linux (RHEL) 6
The calloc function in the glibc package in Red Hat Enterprise Linux (RHEL) 6.7 and 7.2 does not properly initialize memory areas, which might allow context-dependent attackers to cause a denial of service (hang or crash) via unspecified vectors.
Red Hat
glibc: calloc may return non-zero memory
vendor_redhat·2015-08-21·CVSS 7.5
CVE-2015-5229 [HIGH] glibc: calloc may return non-zero memory
glibc: calloc may return non-zero memory
The calloc function in the glibc package in Red Hat Enterprise Linux (RHEL) 6.7 and 7.2 does not properly initialize memory areas, which might allow context-dependent attackers to cause a denial of service (hang or crash) via unspecified vectors.
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.
Package: glibc (Red Hat Enterprise Linux 5) - Not affected
Debian
CVE-2015-5229: glibc - The calloc function in the glibc package in Red Hat Enterprise Linux (RHEL) 6.7 ...
vendor_debian·2015·CVSS 7.5
CVE-2015-5229 [HIGH] CVE-2015-5229: glibc - The calloc function in the glibc package in Red Hat Enterprise Linux (RHEL) 6.7 ...
The calloc function in the glibc package in Red Hat Enterprise Linux (RHEL) 6.7 and 7.2 does not properly initialize memory areas, which might allow context-dependent attackers to cause a denial of service (hang or crash) via unspecified vectors.
Scope: local
bookworm: resolved
bullseye: resolved
forky: resolved
sid: resolved
trixie: resolved
No detection rules found.
No public exploits indexed.
Bugzilla
CVE-2015-5229 glibc: calloc() returns non-zero'ed memory
bugzilla·2015-12-24·CVSS 7.5
CVE-2015-5229 [HIGH] CVE-2015-5229 glibc: calloc() returns non-zero'ed memory
CVE-2015-5229 glibc: calloc() returns non-zero'ed memory
This problem is also in rhel7.2 due to glibc-rh1207032.patch.
Discussion:
Opened duplicate report too fast, while reading customer case.
*** This bug has been marked as a duplicate of bug 1293976 ***
Bugzilla
CVE-2015-5229 glibc: calloc() returns non-zero'ed memory [rhel-7.3.0]
bugzilla·2015-12-23·CVSS 7.5
CVE-2015-5229 [HIGH] CVE-2015-5229 glibc: calloc() returns non-zero'ed memory [rhel-7.3.0]
CVE-2015-5229 glibc: calloc() returns non-zero'ed memory [rhel-7.3.0]
+++ This bug was initially created as a clone of Bug #1246713 +++
Description of problem:
At Facebook we had an app that started hanging and crashing weirdly when going from glibc-2.12-1.149.el6.x86_64 to glibc-2.12-1.163.el6.x86_64. Turns out this patch
glibc-rh1066724.patch
Introduced the problem.
You added the following bit to _int_malloc()
+ /* There are no usable arenas. Fall back to sysmalloc to get a chunk from
+ mmap. */
+ if (__glibc_unlikely (av == NULL))
+ {
+ void *p = sYSMALLOc (nb, av);
+ if (p != NULL)
+ alloc_perturb (p, bytes);
+ return p;
+ }
+
But this isn't ok, alloc_perturb unconditionally memset's the front byte to 0xf, unlike upstream where it checks to see if perturb_byte is set. This needs
Bugzilla
CVE-2015-5229 glibc: calloc may return non-zero memory
bugzilla·2015-08-24·CVSS 7.5
CVE-2015-5229 [HIGH] CVE-2015-5229 glibc: calloc may return non-zero memory
CVE-2015-5229 glibc: calloc may return non-zero memory
It was discovered that the calloc implementation in glibc, as shipped in the Red Hat Enterprise Linux 6.7 GA and 7.2 GA version, could return memory areas which contain non-zero bytes. This could lead to application misbehavior such as hangs or crashes.
Discussion:
This issue has been addressed in the following products:
Red Hat Enterprise Linux 6
Via RHBA-2015:1465 https://rhn.redhat.com/errata/RHBA-2015-1465.html
---
Fixed glibc packages for Red Hat Enterprise Linux 6.7 were available at GA time, but are not included in the installation media.
---
This issue was found to also affect Red Hat Enterprise Linux 7.2. This issue does not affect Red Hat Enterprise Linux 7.0 or 7.1.
---
Acknowledgements:
Red Hat would like to tha
Bugzilla
CVE-2015-5229 glibc: calloc() returns non-zero'ed memory
bugzilla·2015-07-25·CVSS 7.5
CVE-2015-5229 [HIGH] CVE-2015-5229 glibc: calloc() returns non-zero'ed memory
CVE-2015-5229 glibc: calloc() returns non-zero'ed memory
Created attachment 1055966
patch to fix the problem.
Description of problem:
At Facebook we had an app that started hanging and crashing weirdly when going from glibc-2.12-1.149.el6.x86_64 to glibc-2.12-1.163.el6.x86_64. Turns out this patch
glibc-rh1066724.patch
Introduced the problem.
You added the following bit to _int_malloc()
+ /* There are no usable arenas. Fall back to sysmalloc to get a chunk from
+ mmap. */
+ if (__glibc_unlikely (av == NULL))
+ {
+ void *p = sYSMALLOc (nb, av);
+ if (p != NULL)
+ alloc_perturb (p, bytes);
+ return p;
+ }
+
But this isn't ok, alloc_perturb unconditionally memset's the front byte to 0xf, unlike upstream where it checks to see if perturb_byte is set. This needs to be changed to
if (p !
http://rhn.redhat.com/errata/RHSA-2016-0176.htmlhttp://www.oracle.com/technetwork/topics/security/linuxbulletinjan2016-2867209.htmlhttp://www.securityfocus.com/bid/84172https://bugzilla.redhat.com/show_bug.cgi?id=1246713https://bugzilla.redhat.com/show_bug.cgi?id=1256285https://bugzilla.redhat.com/show_bug.cgi?id=1293976https://kc.mcafee.com/corporate/index?page=content&id=SB10150http://rhn.redhat.com/errata/RHSA-2016-0176.htmlhttp://www.oracle.com/technetwork/topics/security/linuxbulletinjan2016-2867209.htmlhttp://www.securityfocus.com/bid/84172https://bugzilla.redhat.com/show_bug.cgi?id=1246713https://bugzilla.redhat.com/show_bug.cgi?id=1256285https://bugzilla.redhat.com/show_bug.cgi?id=1293976https://kc.mcafee.com/corporate/index?page=content&id=SB10150
2016-04-08
Published