Credit for this goes to Andy B (Launchpad Id: u-launchpad-x) who submitted this patch to the gearmand Launchpad on 2014-05-14. The original Launchpad URL for this patch is https://bugs.launchpad.net/gearmand/+bug/1319250.

Andy B wrote:

Steps to reproduce:

1. start gearmand
2. on ipv6 localhost: gearadmin -h ::1 --workers
3. on ipv6 link-local: gearadmin -h fe80::a00:27ff:fe34:3379%eth0 --workers

Actual output for 2:
33 ::e8bf:8995:757f:0%33 - :
.
Actual output for 3:
33 fe80::e8bf:444b:657f:0%33 - :
.

Expected output for 2:
33 ::1 - :
.
Expected output for 3:
33 fe80::a00:27ff:fe34:3379%eth0 - :
.

This is due to struct sockaddr not being big enough to hold struct sockaddr_in6. struct sockaddr_storage is supposed to be used for this. Attached patch fixes this.

I did not observe a crash from this, but it appears that data beyond the end of the structure is being accessed (I've observed the ipv6 scope identifier being the same value as the worker offset, 33 and %33 as shown above, in every case during my research), which may be exploitable to cause a DOS.

I did modify Andy B's patch slightly to also address the !HAVE_ACCEPT4 case. There's no reason I'm aware of to not also use sockaddr_storage with accept(). There are plenty of examples all over the Internet doing so. I think that was just an oversight or perhaps an assumption that any system without accept4() wouldn't also support IPv6.