Possible memory leak in genl_ctrl_probe_by_name()

[Дмитрий Дороговцев]

Hello.

This is a small program using genl_ctrl_resolve(copied from test-genl.c).
Compile: gcc -o test main.c -I libnl-3.2.21/include/
libnl-3.2.21/lib/.libs/libnl-3.a libnl-3.2.21/lib/.libs/libnl-genl-3.a
-lpthread -lm
Run memcheck: valgrind --leak-check=full --show-reachable=yes ./test

I got following output:
...
==24905== HEAP SUMMARY:
==24905==     in use at exit: 112 bytes in 1 blocks
==24905==   total heap usage: 148 allocs, 147 frees, 31,720 bytes allocated
==24905==
==24905== 112 bytes in 1 blocks are definitely lost in loss record 1 of 1
==24905==    at 0x402A5E6: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==24905==    by 0x804F172: nl_cb_alloc (handlers.c:208)
==24905==    by 0x40A84D2: (below main) (libc-start.c:226)
==24905==
==24905== LEAK SUMMARY:
==24905==    definitely lost: 112 bytes in 1 blocks
==24905==    indirectly lost: 0 bytes in 0 blocks
==24905==      possibly lost: 0 bytes in 0 blocks
==24905==    still reachable: 0 bytes in 0 blocks
==24905==         suppressed: 0 bytes in 0 blocks
...

I think it's a bug in genl_ctrl_probe_by_name():

...
if (!(cb = nl_cb_clone(nl_socket_get_cb(sk))))
        goto out_msg_free;
...

Here we increase ref count on sk->s_cb, so i think it should be decremented
later.
With this patch i don't have valgrind memleak anymore:

--- libnl-3.2.21_o/lib/genl/ctrl.c    2013-01-24 14:30:34.000000000 +0200
+++ libnl-3.2.21/lib/genl/ctrl.c    2013-03-29 16:53:12.012950437 +0200
@@ -431,7 +431,8 @@
         err = -NLE_OBJ_NOTFOUND;
         goto errout;
     }
-
+
+    nl_cb_put( sk->s_cb );
     err = genl_family_get_id(family);
     genl_family_put(family);
 errout:

I use libnl-3.2.21 with Ubuntu 12.04 (3.2.0-39-generic-pae kernel).
Sorry for my English, and please let me know if you need additional
information.
Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20130329/32a3a821/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: main.c
Type: text/x-csrc
Size: 1808 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20130329/32a3a821/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.diff
Type: application/octet-stream
Size: 310 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20130329/32a3a821/attachment.obj>