Bad access to IP address in memory

[Julien ÉLIE]

Hi Russ,

>>    case CTnntp:
>>        snprintf(cp->Name, sizeof(cp->Name), "%s:%d",
>>                 cp->Address.ss_family == 0 ? "localhost" : RChostname(cp),
>>                 cp->fd);
>>        break;
>>
>> I wonder if something similar is needed in status, although the results
>> you see still don't look like printing out zeroed memory.

I believe this bug comes from network_sockaddr_sprint because it does not
handle a 0 family value:


bool
network_sockaddr_sprint(char *dst, size_t size, const struct sockaddr *addr)
{
#ifdef HAVE_INET6
    if (addr->sa_family == AF_INET6) {
        [...]
    }
#endif
    if (addr->sa_family == AF_INET) {
        [...]
    } else {
        errno = EAFNOSUPPORT;
        return false;
    }
}


I suggest this patch:

===================================================================
--- lib/network.c       (révision 7873)
+++ lib/network.c       (copie de travail)
@@ -595,6 +595,10 @@
         sin = (const struct sockaddr_in *) addr;
         result = inet_ntop(AF_INET, &sin->sin_addr, dst, size);
         return (result != NULL);
+    } else if (addr->sa_family == 0) {
+        /* Connections from lc.c. */
+        memset(dst, 0, size);
+        return true;
     } else {
         errno = EAFNOSUPPORT;
         return false;



With it, the display is now fine.
I also tried to write '-' to dst and it also looks fine (IPv6 max length):

localhost
    seconds: 280            duplicates: 0           ip address: ----------------------------------------------



This value does not seem to change afterwards.
And it explains why the value kept being modified:  network_sockaddr_sprint is
invoked each time the status is printed.  As it does nothing for localhost
except "errno = EAFNOSUPPORT", the contents of "dst" is always different
(an uninitialized part of previously freed memory).


>>    valgrind --trace-children=yes --track-fds=yes --log-file=inn-valgrind /home/news/bin/innd
>
> I'm not sure.  When I've done this before, I don't recall having any
> special trouble.

10:23 news at news % valgrind --trace-children=yes --track-fds=yes --log-file=inn-valgrind /home/news/bin/innd
[nothing happens]

Jul  5 10:23:33 news innd: cannot exec innbind for 0.0.0.0,119: Permission denied
Jul  5 10:23:35 news innd: innbind returned no output, assuming failure
Jul  5 10:23:35 news innd: innbind failed for 0.0.0.0,119
Jul  5 10:23:35 news innd: cannot exec innbind for ::,119: Permission denied
Jul  5 10:23:37 news innd: innbind returned no output, assuming failure
Jul  5 10:23:37 news innd: innbind failed for ::,119
Jul  5 10:23:37 news innd: SERVER cant listen on any sockets


The same being root:

10:23 root at news # valgrind --trace-children=yes --track-fds=yes --log-file=inn-valgrind /home/news/bin/innd
valgrind: /home/news/bin/innd: Permission denied


With rc.news, it is the same.
innbind may not be happy being launched inside valgrind (?)

-- 
Julien ÉLIE

« Tous les matins, j'apporte à ma femme le café au lit.
  Elle n'a plus qu'à le moudre. » (Coluche)