No, you misunderstand: "some fields" weren't added to struct ifreq; rather,
  a serious bug in the definition of struct ifreq was fixed: it used the 4.3
  style sockaddr (which is of unspecified length, because it's supposed to be
  used as a fixed header on a variable-length structure) as static storage.
  4.4 introduced sockaddr_storage as a fix for this but somehow this API was
  missed (much as a few filesystem syscalls were missed when off_t became
  64 bits and required nasty versioning hacks).

  This meant that ioctls using this structure (all the IF ioctls) had
  truncation and overrun problems, which the compiler errored on when we
  started building the system with SSP -- but the bugs were always there.

Not quite - the definition of SIOCGIFCONF always had the notion that
there was a full sockaddr of whatever type, and that you'd the next
ifreq would follow that one (of whatever length).  This is complicated,
and requires copies for alignment, but I don't think it was
intrinsically unsafe (just bug-prone because of complexity).  It seems
that other ioctls returned data into a struct ifreq, though, and that is
the brokenness that had to be addressed.


But, really the way forward is to take all code that uses this ioctl and
make it use getifaddrs instead, at least via an autoconf/etc. test for
platforms that support getifaddrs.