Constant resolver crashes after fiesty upgrade

There are really two separate issues here:

1) At some point (I think during the upgrade to fiesty, possibly for the purpose of ipv6 configuration), Ubuntu decided to "beautify" my hosts file. I use Mike's ad-blocking hosts file (see http://everythingisnt.com/hosts.html) which points several advertising URLs to 127.0.0.1, and the beautification code collapsed this all into a single entry. This is as annoying as it is pointless.

2) The really long line that this produced in /etc/hosts crashes the glibc resolver code.

Background/Evidence:

After upgrading to Fiesty, I found that several network applications broke, including Java, telnet, wget, firefox, etc. They would all work normally most of the time, except that Java would regularly crash firefox. The trace from Java invariably showed up as happening here:

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libc.so.6+0x6f34c] memcpy+0x1c
C [libc.so.6+0x58001] _IO_getline+0x41
C [libc.so.6+0x602eb] fgets_unlocked+0x5b
C [libnss_files.so.2+0x2f8a]
C [libnss_files.so.2+0x36df] _nss_files_gethostbyname2_r+0xaf

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j java.net.Inet6AddressImpl.lookupAllHostAddr(Ljava/lang/String;)[Ljava/net/InetAddress;+0
j java.net.InetAddress$1.lookupAllHostAddr(Ljava/lang/String;)[Ljava/net/InetAddress;+4
j java.net.InetAddress.getAddressFromNameService(Ljava/lang/String;)Ljava/lang/Object;+17
[...]

Using gdb on "telnet localhost" gave me this:

[...]
Program received signal SIGSEGV, Segmentation fault.
0xb7d3d97e in ?? () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0 0xb7d3d97e in ?? () from /lib/tls/i686/cmov/libc.so.6
#1 0xb7d3e998 in getaddrinfo () from /lib/tls/i686/cmov/libc.so.6
[...]

And strace on "telnet localhost" gave me this:

[...]
munmap(0xb7f63000, 4096) = 0
open("/etc/hosts", O_RDONLY) = 3
fcntl64(3, F_GETFD) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=257457, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f63000
read(3, "\n127.0.0.1 localhost loopback\n12"..., 4096) = 4096
read(3, "s.autotrader.co.za adserving.aut"..., 4096) = 4096
close(3) = 0
munmap(0xb7f63000, 4096) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV (core dumped) +++
Process 8081 detached

I have not checked the source, but my gut feeling is that the code is not correctly handling the case of not finding a newline within 4K chars and is overrunning the end of the buffer. I'm at a loss as to how this would be exploited, but any buffer overrun in something as commonly used as the resolver code alarms me, so I've checked the security vulnerability checkbox just in case.

I will attach a hosts file that reproduces the issue.