### Description
I noticed at least one regression while testing out kamailio 5.6.0: the same configuration yields a different result after upgrading from 5.5.4. More specifically, this xlog line/statement: ``` xlog("L_CRIT", "vn is $vn(cli_164_src_noccgr), to int is $(vn(cli_164_src_noccgr){s.int})\n"); ``` Prints the following in syslog for `$vn(cli_164_src_noccgr) = "2152157200"`: * On 5.5.4: `vn is 2152157200, to int is 2152157200` * On 5.6.0~rc1: `vn is 2152157200, to int is`
I've only tested this with a couple of values and it doesn't always happen, for example for `$vn(cli_164_src_noccgr) = "2103260000"` the issue doesn't manifest.
Only thing I could think of is 2103260000 can be represented (unsigned) by 31 bits, whereas you need 32 bits for 2152157200? I skimmed over pv_trans.c and there weren't any obvious commits that could take the blame, at least not to me. Perhaps this is a compiler/glibc thing? ### Troubleshooting
#### Reproduction Try the transformation above with various values for the pseudovariable being transformed, I guess. <!-- If the issue can be reproduced, describe how it can be done. --> ### Additional Information
``` version: kamailio 5.6.0-rc1 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled with gcc 10.2.1 ```
* **Operating System**: ``` Linux sbcprov0-stage-lhe0-cn1 5.10.0-10-amd64 #1 SMP Debian 5.10.84-1 (2021-12-08) x86_64 GNU/Linux ```
Thanks for the report. To make it clear and easier to reproduce: the issue happens on the same environment (operating system, virtual machine etc..), the only difference are the kamailio versions?
During the past year there were a lot of checks added to detect out of bounds value (reported by fuzzing and static analysis) because they can have unexpected behaviour as per C specs and may result in security issues, although some compilers/architectures handle them smoothly. The changes were done in the common functions located in the core.
In this particular case, it makes checks that the value is in between INT_MIN and INT_MAX (which should be -2147483648 and 2147483647).
Maybe it would be better to understand what you need and decide what is the better option for it. The example is like converting string to int and then the resulting int back to string in order to print it, which sounds useless, but can be just as an example here.
To answer @henningw's question, yes. The steps were: * Produce the error on a (nearly clean) debian bullseye installation with kamailio 5.6.0 * On the same machine, change back to 5.5 repo and execute: `apt-get install kamailio=5.5.4+bpo11 kamailio-dbg=5.5.4+bpo11 kamailio-extra-modules=5.5.4+bpo11 kamailio-geoip2-modules=5.5.4+bpo11 kamailio-json-modules=5.5.4+bpo11 kamailio-mysql-modules=5.5.4+bpo11 kamailio-outbound-modules=5.5.4+bpo11 kamailio-phonenum-modules=5.5.4+bpo11 kamailio-presence-modules=5.5.4+bpo11 kamailio-python-modules=5.5.4+bpo11 kamailio-python3-modules=5.5.4+bpo11 kamailio-redis-modules=5.5.4+bpo11 kamailio-sctp-modules=5.5.4+bpo11 kamailio-snmpstats-modules=5.5.4+bpo11 kamailio-tls-modules=5.5.4+bpo11 kamailio-xml-modules=5.5.4+bpo11` * Run the test again (now the error doesn't appear) The output of `kamailio -v` after the downgrade is: ``` version: kamailio 5.5.4 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled with gcc 10.2.1 ```
@miconda Actually the second conversion (to string by xlog) only took place during my debugging. Originally I stumbled upon this because the mysql module would report failures after upgrading to 5.6. The actual use case was:
``` sql_pvquery("ca", "select lrn from telephony_lrn where number_from = $(vn(cli_164_src_noccgr){s.int})", "$vn(src_portnet)"); ``` This produces invalid SQL on 5.6.0~rc1, because the resulting query is: `select lrn from telephony_lrn where number_from = ;` I make the conversion here because `telephony_lrn`.`number_from` is of type INT, but I'm not sure if it's needed or if the sqlops module handles pv data types any differently, this particular statement was written several years ago and I don't remember if the transformation is required for this query or if I was merely OCDing.
Nevertheless, I discovered this discrepancy during testing and I thought I'd create an issue before 5.6.0 is released in case people thought it's a problem for them too.
You do not need `$(vn(cli_164_src_noccgr){s.int})` int the `sql_pvquery()` parameter, because you convert a string to integer via `{s.int}` and then it is back converted to string to build the full parameter there. No quotes are added around string variables, there is a transformation for that, iirc.
Integer values are needed only when doing arithmetic operations or when a function parameter requires a single integer value.
I am closing this one because it was a useless conversion for this case and value overflow from int point of view.
Closed #3116 as completed.
To anyone else stumbling upon this, I solved my issue by using the following transformation: ``` $(vn(ru_164_dest_noccgr){sql.val}{s.unquote}) ``` instead of: ``` $(vn(ru_164_dest_noccgr){s.int}) ```
Thanks to everyone who looked into this!
-
Daniel-Constantin Mierla -
George Diamantopoulos
-
Henning Westerholt