Error: "corrupted double-linked list"

[entrity]

Describe the bug
When I run jq v1.6 with certain input, it results in the following error:

*** Error in `jq': corrupted double-linked list: 0x00000000021260e0 ***
======= Backtrace: =========
/usr/lib64/libc.so.6(+0x7bbf7)[0x7f6d6887ebf7]
/usr/lib64/libc.so.6(+0x7d22a)[0x7f6d6888022a]
/usr/lib64/libjq.so.1(+0x16dbb)[0x7f6d6915fdbb]
/usr/lib64/libjq.so.1(jq_teardown+0x18)[0x7f6d69161dc8]
jq[0x401d16]
/usr/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f6d68824af5]
jq[0x4034aa]

To Reproduce

cat <<-EOF | jq -jaRs .
************************* 1. row *************************
Slave_IO_State: Waiting for master to send event
Master_Host: dataraptor-db
Master_User: replicant
Master_Port: 5000
Connect_Retry: 60
Master_Log_File: mysql-bin.041132
Read_Master_Log_Pos: 963676208
Relay_Log_File: db-slave-1-relay-bin.000002
Relay_Log_Pos: 10095630
Relay_Master_Log_File: mysql-bin.041132
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: dataraptor_production
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 963676208
Relay_Log_Space: 10095944
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: Yes
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_SSL_Crl:
Master_SSL_Crlpath:
Using_Gtid: No
Gtid_IO_Pos:
Replicate_Do_Domain_Ids:
Replicate_Ignore_Domain_Ids:
Parallel_Mode: conservative
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
Slave_DDL_Groups: 231
Slave_Non_Transactional_Groups: 0
Slave_Transactional_Groups: 3192853
EOF

Expected behavior
I expected it would output a JSON-escaped (js-escaped) version of the input string.

Environment (please complete the following information):

• CentOS 7 & Ubuntu 20.04
• jq version 1.6

[pkoppstein]

On a Mac I've been unable to reproduce the problem using the following versions (as reported by jq --version):

jq-1.5
jq-1.6
jq-1.6-129-g80052e5-dirty

Would you be able to run your example against the master version of jq?

[entrity]

@pkoppstein I've just built master (d18b2d0), and as you say, I can't reproduce it on master.

[pkoppstein]

@entrity - Thanks for the update.

[nescio007]

I stumbled upon the same issue today with the jq version from the arch linux repositories and might be able to add some datapoints:

For me, the crash occurs when running

echo 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' | jq -arR .

However, it appears the crash only occurs when

1. the input length is 52-55 characters (51 x and 56 x do not trigger the crash)
2. both -a and -r are given (removing either results in no crash)
3. stdin of jq is somehow redirected (cmd | jq -arR . and jq -arR . <<< text both crash, but starting jq -arR . and then typing 52 x does not)

Environment:

• arch linux
• jq --version reports jq-1.6
• pacman -Q jq reports jq 1.6-4
• sha256sum of /bin/jq is 7531930ff879a2399f84e7a3ae2d7b24cbe0c0363b3ecf56aaa19b12c101a29a

As above, when rebuilding from master (a9f97e9) I was unable to trigger the crash. However, I was able to reproduce it when rebuildling jq from the latest release sources (https://github.com/stedolan/jq/releases/download/jq-1.6/jq-1.6.tar.gz).

[nicowilliams]

Thanks for this report. We'll want to fuzz not just the JSON parser but also the "raw" parser.