ENCAP module. The ms_encap function is responsible for dispatching the
command handler and then the modules will eventually be reloaded.
However, if the ENCAP module is reloaded to a different address, the
stack now contains the address of a function that no longer exists.
Also, in this version of the IRCd, the module restarting functionality
was located in a function that is itself located in a module, so things
will also go badly if that module is reloaded to a different address,
too.
Return immediately from the command handler and have the event loop
call the function responsible for reloading the modules instead.
c.f. release/3.5 commit db05a36210
Reported-by: mniip (Freenode)
I run into this code even with a single kind of scanner with a single
port, so I'm not even sure how it thinks it already exists.
Perhaps it's being parsed twice, or something similar.
c.f. issue #229
When certificate validation fails, the certificate fingerprint won't be
calculated, resulting in an attempt to format NULL into a log line
showing the fingerprint. Instead, add a different error message for
missing fingerprint (i.e. validation failed).
When both account-tag and server-time are present but the client
doesn't have the first (i == 0) of these enabled. They will get
an erroneous ';' after the '@'.
Track whether or not there are tags present, and use this to
determine whether to add the ';' or not. Also remove the extra
function that loops over all of the tags by using this flag to
handle the case where there are no tags being written.
Build the same message but send it to the local client first,
so that the echo-message capability works. But don't do it when
sending a message to yourself.
As well as leaking a connid and leaving the connection open,
these calls to free_client() leave the client in the unknown_list
causing check_unknowns_list() to crash when either ptr->data
(ptr being the freed client_p->localClient->tnode) is NULL or
when client_p->localClient is NULL.
Flag the client as an IO error so that we don't try to send it
any data (as this is not a normal plaintext connection).
==00:00:01:09.081 1762== 48 bytes in 2 blocks are definitely lost in loss record 545 of 991
==00:00:01:09.081 1762== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==00:00:01:09.081 1762== by 0x56C14A2: rb_malloc (rb_memory.h:41)
==00:00:01:09.081 1762== by 0x56C177C: rb_bh_alloc (balloc.c:189)
==00:00:01:09.081 1762== by 0x56CA0A9: rb_make_rb_dlink_node (tools.c:65)
==00:00:01:09.081 1762== by 0x4E52D85: cache_file (cache.c:146)
==00:00:01:09.081 1762== by 0x4E52AC3: init_cache (cache.c:67)
==00:00:01:09.081 1762== by 0x4E69530: charybdis_main (ircd.c:762)
==00:00:01:09.081 1762== by 0x400815: main (main.c:8)
==00:00:01:09.100 1762== 2,808 bytes in 117 blocks are definitely lost in loss record 960 of 991
==00:00:01:09.100 1762== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==00:00:01:09.100 1762== by 0x56C14A2: rb_malloc (rb_memory.h:41)
==00:00:01:09.100 1762== by 0x56C177C: rb_bh_alloc (balloc.c:189)
==00:00:01:09.100 1762== by 0x56CA0A9: rb_make_rb_dlink_node (tools.c:65)
==00:00:01:09.100 1762== by 0x4E52D85: cache_file (cache.c:146)
==00:00:01:09.100 1762== by 0x4E5337A: load_help (cache.c:301)
==00:00:01:09.100 1762== by 0x4E698AA: charybdis_main (ircd.c:848)
==00:00:01:09.100 1762== by 0x400815: main (main.c:8)
==00:00:01:09.100 1762== 5,328 (5,304 direct, 24 indirect) bytes in 221 blocks are definitely lost in loss record 971 of 991
==00:00:01:09.100 1762== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==00:00:01:09.100 1762== by 0x56C14A2: rb_malloc (rb_memory.h:41)
==00:00:01:09.100 1762== by 0x56C177C: rb_bh_alloc (balloc.c:189)
==00:00:01:09.100 1762== by 0x56CA0A9: rb_make_rb_dlink_node (tools.c:65)
==00:00:01:09.100 1762== by 0x4E52D85: cache_file (cache.c:146)
==00:00:01:09.100 1762== by 0x4E53278: load_help (cache.c:266)
==00:00:01:09.100 1762== by 0x4E698AA: charybdis_main (ircd.c:848)
==00:00:01:09.100 1762== by 0x400815: main (main.c:8)
==01:17:20:36.920 5966== 429 bytes in 3 blocks are possibly lost in loss record 899 of 1,020
==01:17:20:36.920 5966== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==01:17:20:36.920 5966== by 0x4E73867: rb_strdup (rb_memory.h:70)
==01:17:20:36.920 5966== by 0x4E7674C: conf_set_connect_fingerprint (newconf.c:1421)
==01:17:20:36.920 5966== by 0x4E78D55: conf_call_set (newconf.c:2562)
==01:17:20:36.920 5966== by 0x4E6A33D: yyparse (ircd_parser.y:215)
==01:17:20:36.920 5966== by 0x4E7FFC7: read_conf (s_conf.c:834)
==01:17:20:36.920 5966== by 0x4E81718: read_conf_files (s_conf.c:1419)
==01:17:20:36.920 5966== by 0x4E69567: charybdis_main (ircd.c:775)
==01:17:20:36.920 5966== by 0x400815: main (main.c:8)
==01:17:20:36.919 5966== 280 bytes in 8 blocks are definitely lost in loss record 876 of 1,020
==01:17:20:36.919 5966== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==01:17:20:36.919 5966== by 0x4E93F4F: rb_strdup (rb_memory.h:70)
==01:17:20:36.919 5966== by 0x4E95280: ssl_process_cipher_string (sslproc.c:476)
==01:17:20:36.919 5966== by 0x4E95540: ssl_process_cmd_recv (sslproc.c:561)
==01:17:20:36.919 5966== by 0x4E9582A: ssl_read_ctl (sslproc.c:632)
==01:17:20:36.919 5966== by 0x56CBAB6: rb_select_epoll (epoll.c:199)
==01:17:20:36.919 5966== by 0x56C4EB5: rb_select (commio.c:2085)
==01:17:20:36.919 5966== by 0x56C7FD6: rb_lib_loop (rb_lib.c:228)
==01:17:20:36.919 5966== by 0x4E69987: charybdis_main (ircd.c:872)
==01:17:20:36.919 5966== by 0x400815: main (main.c:8)
==01:17:20:36.906 5966== 48 bytes in 1 blocks are definitely lost in loss record 544 of 1,020
==01:17:20:36.906 5966== at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==01:17:20:36.906 5966== by 0x4E93F0C: rb_malloc (rb_memory.h:41)
==01:17:20:36.906 5966== by 0x4E961E8: start_zlib_session (sslproc.c:901)
==01:17:20:36.906 5966== by 0x4E86FAC: server_estab (s_serv.c:877)
==01:17:20:36.906 5966== by 0x13B2921A: mr_server (m_server.c:304)
==01:17:20:36.906 5966== by 0x4E7AF03: handle_command (parse.c:241)
==01:17:20:36.906 5966== by 0x4E7A96A: parse (parse.c:157)
==01:17:20:36.906 5966== by 0x4E7A3DC: client_dopacket (packet.c:354)
==01:17:20:36.906 5966== by 0x4E798D6: parse_client_queued (packet.c:98)
==01:17:20:36.906 5966== by 0x4E79FAC: read_packet (packet.c:282)
==01:17:20:36.906 5966== by 0x56CBAB6: rb_select_epoll (epoll.c:199)
==01:17:20:36.906 5966== by 0x56C4EB5: rb_select (commio.c:2085)
[ircd/match.c:316]: (error) Shifting a negative value is undefined behaviour
[librb/src/patricia.c:55]: (error) Shifting a negative value is undefined behaviour
[modules/m_alias.c:64]: (portability) '(void*)message' is of type 'void *'. When using void pointers in calculations, the behaviour is undefined.
[modules/m_time.c:111]: (warning) %u in format string (no. 9) requires 'unsigned int' but the argument type is 'signed int'.
[modules/m_time.c:111]: (warning) %u in format string (no. 10) requires 'unsigned int' but the argument type is 'signed int'.
[librb/src/dictionary.c:819]: (warning) %d in format string (no. 3) requires 'int' but the argument type is 'unsigned int'.
[librb/src/radixtree.c:1080]: (warning) %d in format string (no. 3) requires 'int' but the argument type is 'unsigned int'.
[ircd/s_user.c:351] -> [ircd/s_user.c:357]: (warning) Either the condition '0!=source_p' is redundant or there is possible null pointer dereference: source_p.
[extensions/ip_cloaking_3.0.c:109]: (warning, inconclusive) The buffer 'buf' may not be null-terminated after the call to strncpy().
[ircd/chmode.c:256]: (style) Clarify calculation precedence for '&' and '?'.
[modules/m_help.c:100]: (style) Clarify calculation precedence for '&' and '?'.
[modules/m_knock.c:169]: (style) Clarify calculation precedence for '&' and '?'.
[modules/m_stats.c:628]: (style) Clarify calculation precedence for '&' and '?'.
[modules/m_stats.c:727]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:601]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:704]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:739]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:763]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:768]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:774]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:781]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:786]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:791]: (style) Clarify calculation precedence for '&' and '?'.
[librb/src/radixtree.c:804]: (style) Clarify calculation precedence for '&' and '?'.
[ircd/wsproc.c:372]: (style) Unused variable: len
[modules/core/m_modules.c:382]: (style) Unused variable: i
[modules/m_stats.c:741]: (style) Unused variable: amsg
[ircd/authproc.c:390]: (style) Unused variable: iter
[ircd/authproc.c:391]: (style) Unused variable: client_p
The CHALLENGE functionality will set opername but not privset --
if an oper performs a WHOIS on someone currently half-way through
a challenge we will perform a NULL dereference.
Related to ircd-seven commit d7b05f7583babf6
The changes made in this file are detailed in release/3.5 commits
4d89c83c32 through ecfdcb08e8 inclusive.
Some slight alterations are necessary; librb instead of libratbox,
snprintf() instead of rb_snprintf(), etc. Also, release/4 has
offline certificate digesting functionality. For more insight,
simply diff the gnutls.c between release/3.5 and release/4.
The changes made in this file are detailed in release/3.5 commits
295c8f7d37 through 265dc4e53c inclusive.
Some slight alterations are necessary; librb instead of libratbox,
snprintf() instead of rb_snprintf(), etc. Also, release/4 has
offline certificate digesting functionality. For more insight,
simply diff the mbedtls.c between release/3.5 and release/4.
The changes made in this file are detailed in release/3.5 commits
1f30c8943b through 92c04c6b9d inclusive.
Some slight alterations are necessary; librb instead of libratbox,
snprintf() instead of rb_snprintf(), etc. Also, release/4 has
offline certificate digesting functionality. For more insight,
simply diff the openssl.c between release/3.5 and release/4.
Links that are 'no-export' are not distributed to the rest of the IRC network (including local peers).
This provides a core primitive for 'anycasting' services (but the actual issue of synchronizing data in
a services package is left to the authors of the services package).
