All comparison equal to Nan

I know it is not an asterisk bug, but it happened already on two sites, so I think it is worth reporting. Without any relevant change, one morning every comparison in the asterisk dialplan resolves to Nan with disastrous results. Asterisk is running on CentOS 7 on a Redhat virtualization platform I don’t control with QEMU Virtual CPU version (cpu64-rhel6) CPU, just in case, it might be of any interest. Asterisk was running fine with the same diaplan for many years before waking up one morning in this hell.

For example, this simple code:

    9999 => {
         if (1==2) {
            NoOp(What is happening);
         } else {
           NoOp(All good);

Produces the following output. As you can see the 1==2 resolved in nan

-- Executing [9999@authenticated:1] GotoIf("SIP/209-AERIO-00000000", "nan?2:4") in new stack
-- Goto (authenticated,9999,2)
-- Executing [9999@authenticated:2] NoOp("SIP/209-AERIO-00000000", "What is happening") in new stack
-- Executing [9999@authenticated:3] Goto("SIP/209-AERIO-00000000", "5") in new stack
-- Goto (authenticated,9999,5)
-- Executing [9999@authenticated:5] NoOp("SIP/209-AERIO-00000000", "Finish if_authenticated_2699") in new stack
-- Executing [9999@authenticated:6] Hangup("SIP/209-AERIO-00000000", "") in new stack

No matter what comparison is done, the result is always nan.

Other example:

exten => 9998,1,GotoIf($["one"=="two"]?wrong:good)
exten => 9998,n(wrong),NoOp(What is happening?)
exten => 9998,n(wrong),Hangup()
exten => 9998,n(good),NoOp(All good)
exten => 9998,n(good),Hangup()

Produces the following result:

-- Executing [9998@authenticated:1] GotoIf("SIP/209-AERIO-00000004", "nan?wrong:good") in new stack
-- Goto (authenticated,9998,2)
-- Executing [9998@authenticated:2] NoOp("SIP/209-AERIO-00000004", "What is happening?") in new stack
-- Executing [9998@authenticated:3] Hangup("SIP/209-AERIO-00000004", "") in new stack

Other example:

exten => 9997,1,GotoIf($[99<50]?wrong:good)
exten => 9997,n(wrong),NoOp(What is happening?)
exten => 9997,n(wrong),Hangup()
exten => 9997,n(good),NoOp(All good)
exten => 9997,n(good),Hangup()

Produces the following output

-- Executing [9997@authenticated:1] GotoIf("SIP/209-AERIO-00000006", "nan?wrong:good") in new stack
-- Goto (authenticated,9997,2)
-- Executing [9997@authenticated:2] NoOp("SIP/209-AERIO-00000006", "What is happening?") in new stack
-- Executing [9997@authenticated:3] Hangup("SIP/209-AERIO-00000006", "") in new stack

Is this not the same issue as in

That one is attributed to a bug in glibc.

yum downgrade glibc-devel glibc glibc-common glibc-headers

systemctl restart asterisk

There was a similar thread on the forum and was solved with the above commands

The problem seems to be this security fix: 26649 – (CVE-2020-29573) printf should handle non-normal x86 long double numbers gracefully (CVE-2020-29573)

I’m not sure what code in Asterisk triggers this new behaviour, but this is clearly the source new “nan” text now produced by evaluating conditions.

The problem with the “nan” output was fixed in package glibc-2.17-323.el7_9.x86_64 (1925204 – glibc: printf of long double with a value of 0 results in "nan" [rhel-7.9.z]). With that release, the conditional evaluation to “nan” problem is gone.

So now, if you update CentOS and then run yum downgrade glibc, you’d get the broken version…

1 Like

Thanks Red Hat Customer Portal - Access to 24x7 support and knowledge

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.