Fix _nl_find_msg malloc failure case, and callers.

This patch fixes two issues, and perhaps should be two distinct commits,
but I present it here as one for the sake of completeness.

Commit 006dd86111c44572dbd3b26e9c63dd0f834d7762 fails to check malloc's
return in intl/dcigettext.c (_nl_find_msg):
~~~
      freemem_size = INITIAL_BLOCK_SIZE;
      newmem = (transmem_block_t *) malloc (freemem_size);
...
      newmem->next = transmem_list;
      transmem_list = newmem;
~~~
If malloc fails then newmem is NULL then newmem->next results in a
fault.

The fix is easy enough, check for newmem != NULL, and fall through to
the error condition below which returns (char *) -1 e.g. resource error.

The problem is that returning (char *) -1  will break all sorts of other
code, so while what we did is correct, the real failure case fix is
slightly broader.

There are 4 other places where _nl_find_msg is called, one is OK, the
other three are fixed to handle -1 error return value.

No regressions on x86-64 or x86.

However, no regressions isn't really a useful metric for this code.

The change was tested as documented here:
http://sourceware.org/glibc/wiki/Testing/WhiteBox
using SystemTap for fault injection to simulate malloc failure.

---

2013-05-03  Carlos O'Donell  <carlos at redhat.com>

	[BZ #15441]
	* intl/dcigettext.c (DCIGETTEXT): Skip translating if _nl_find_msg
	returns -1.
	(_nl_find_msg): Return -1 if recursive call returned -1. If newmem is
	null return -1.
	* intl/loadmsgcat.c (_nl_load_domain): If _nl_find_msg returns -1 abort
	loading the domain.

1 files changed, 2 insertions, 2 deletions

diff --git a/NEWS b/NEWS
index 970c53b614..152e7a4caa 100644
--- a/NEWS
+++ b/NEWS
@@ -17,8 +17,8 @@ Version 2.18
   15085, 15086, 15160, 15214, 15221, 15232, 15234, 15283, 15285, 15287,
   15304, 15305, 15307, 15309, 15327, 15330, 15335, 15336, 15337, 15339,
   15342, 15346, 15359, 15361, 15366, 15380, 15394, 15395, 15405, 15406,
-  15409, 15416, 15418, 15419, 15423, 15424, 15426, 15429, 15442, 15448,
-  15480, 15485, 15488, 15490, 15493, 15497, 15506.
+  15409, 15416, 15418, 15419, 15423, 15424, 15426, 15429, 15441, 15442,
+  15448, 15480, 15485, 15488, 15490, 15493, 15497, 15506.
 
 * CVE-2013-0242 Buffer overrun in regexp matcher has been fixed (Bugzilla
   #15078).