Bug 280514 – <dev-libs/apr-1.3.8, <dev-libs/apr-util-1.3.9 Multiple Integer overflows (CVE-2009-2412)

• Status: RESOLVED FIXED
• Product: Gentoo Security

[Description Alex Legler (RETIRED) 2009-08-05 23:26:28 UTC]

From Secunia:
Some vulnerabilities have been reported in APR-util, which can potentially be exploited to cause a DoS (Denial of Service) or compromise an application using the library.

The vulnerabilities are caused due to integer overflow errors in the "apr_rmm_malloc()", "apr_rmm_calloc()", and "apr_rmm_realloc()" functions in misc/apr_rmm.c when aligning relocatable memory blocks, which can potentially be exploited to cause buffer overflows.

[Comment 1 Alex Legler (RETIRED) 2009-08-05 23:27:55 UTC]

Patches at $URL, new releases are expected soon as well.

CC'ing infra.

[Comment 2 Arfrever Frehtes Taifersar Arahesis (RETIRED) 2009-08-06 13:00:11 UTC]

dev-libs/apr-1.3.8 and dev-libs/apr-util-1.3.9 are now in the tree.

[Comment 3 Arfrever Frehtes Taifersar Arahesis (RETIRED) 2009-08-06 13:01:49 UTC]

Please stabilize dev-libs/apr-1.3.8 and dev-libs/apr-util-1.3.9.

[Comment 4 Alex Legler (RETIRED) 2009-08-06 13:02:47 UTC]

Arches, please test and mark stable:
=dev-libs/apr-1.3.8
=dev-libs/apr-util-1.3.9
Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86"

Please note this is a high priority stabilization.

[Comment 5 Alex Legler (RETIRED) 2009-08-06 13:30:36 UTC]

amd64 stable.

Also tested successfully in my x86 chroot, but not marked stable in case anyone from x86 wants to test themselves.

[Comment 6 Alex Legler (RETIRED) 2009-08-06 13:47:19 UTC]

GLSA draft filed.

[Comment 7 Markus Meier 2009-08-06 21:53:27 UTC]

x86 stable

[Comment 8 Diego Elio Pettenò (RETIRED) 2009-08-07 11:19:29 UTC]

Uuuh has somebody tested this with the stable Apache? Double-checked and rebuilt on my server but it fails to start (unable to bind the socket on port 80) with the new apr, works fine with 1.3.5…

[Comment 9 Diego Elio Pettenò (RETIRED) 2009-08-07 12:11:45 UTC]

Okay so this breaks badly on older kernels, like 2.6.26 which is widely used for vservers.

Can we have more speed and less haste?

[Comment 10 Robert Buchholz (RETIRED) 2009-08-07 12:58:48 UTC]

removing arches, readding x86, you may want to drop stable again.

The patches in $URL should apply to 1.3.5 as well, so backporting seems a more feasible approach to get it fixed timely.

[Comment 11 Diego Elio Pettenò (RETIRED) 2009-08-07 13:06:40 UTC]

amd64 as well (found the issue on that to begin with)

[Comment 12 Christian Faulhammer (RETIRED) 2009-08-07 16:32:51 UTC]

x86 reverted to testing.

[Comment 13 Robin Johnson 2009-08-07 20:45:24 UTC]

Can somebody please backport?

[Comment 14 Stefan Behte (RETIRED) 2009-08-08 02:45:54 UTC]

FYI: Patches apply cleanly to apr-1.3.5 and apr-util-1.3.7.
Unfortunately I can't commit.

[Comment 15 Arfrever Frehtes Taifersar Arahesis (RETIRED) 2009-08-10 03:34:09 UTC]

I added "cloexec" USE flag for dev-libs/apr-1.3.8. Users, who want to build APR on systems with newer kernels and use it on systems with older kernels, should disable "cloexec" USE flag.

[Comment 16 Robert Buchholz (RETIRED) 2009-08-10 11:44:58 UTC]

Arches, please test and mark stable:
=dev-libs/apr-1.3.8
=dev-libs/apr-util-1.3.9
Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86"

[Comment 17 Tobias Klausmann (RETIRED) 2009-08-10 15:59:00 UTC]

Both stable on alpha.

[Comment 18 Markus Meier 2009-08-10 22:36:06 UTC]

x86 stable

[Comment 19 Jeroen Roovers (RETIRED) 2009-08-11 23:29:24 UTC]

Stable for HPPA.

[Comment 20 Raúl Porcel (RETIRED) 2009-08-14 13:54:20 UTC]

arm/ia64/s390/sh/sparc stable 

[Comment 21 Alex Legler (RETIRED) 2009-08-20 12:08:31 UTC]

pcc, pcc64: ping!

[Comment 22 nixnut (RETIRED) 2009-08-23 08:24:11 UTC]

ppc stable

[Comment 23 Brent Baude (RETIRED) 2009-08-24 14:55:17 UTC]

ppc64 done

[Comment 24 Alex Legler (RETIRED) 2009-08-24 20:29:53 UTC]

GLSA already filed, pending 2 approvals.

[Comment 25 Alex Legler (RETIRED) 2009-09-09 13:31:12 UTC]

GLSA 200909-03, sorry for the delay.