A use-after-free in the function l2capreassemblesdu of the file net/bluetooth/l2capcore.c of the component Bluetooth in Linux Kernel could allow a remote authenticated attacker from within the local network to cause an unknown impact.

Summary Due to unchecked multiplications, an integer overflow may occur, causing a fatal error. Impact Denial of Service Description The function [shuffle(int[] input)](https://github.com/xerial/snappy-java/blob/05c39b2ca9b5b7b39611529cc302d3d796329611/src/main/java/org/xerial/snappy/BitShuffle.java#L107) in the file BitShuffle.java receives an array of integers and applies a bit shuffle on it. It does so by multiplying the length by 4 and passing it to the natively compiled shuffle function.

java public static byte[] shuffle(int[] input) throws IOException { byte[] output = new byte[input.length 4]; int numProcessed = impl.shuffle(input, 0, 4, input.length 4, output, 0); assert(numProcessed == input.length 4); return output; }

Since the length is not tested, the multiplication by four can cause an integer overflow and become a smaller value than the true size, or even zero or negative. In the case of a negative value, a “java.lang.NegativeArraySizeException” exception will raise, which can crash the program. In a case of a value that is zero or too small, the code that afterwards references the shuffled array will assume a bigger size of the array, which might cause exceptions such as “java.lang.ArrayIndexOutOfBoundsException”. The same issue exists also when using the “shuffle” functions that receive a double, float, long and short, each using a different multiplier that may cause the same issue.

Steps To Reproduce Compile and run the following code:

java package org.example; import org.xerial.snappy.BitShuffle;

import java.io.;

public class Main {

public static void main(String[] args) throws IOException { int[] original = new int[0x40000000]; byte[] shuffled = BitShuffle.shuffle(original); System.out.println(shuffled[0]); } }

The program will crash, showing the following error (or similar):

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0 at org.example.Main.main(Main.java:12)

Process finished with exit code 1

Alternatively - compile and run the following code:

java package org.example; import org.xerial.snappy.BitShuffle;

import java.io.;

public class Main {

public static void main(String[] args) throws IOException { int[] original = new int[0x20000000]; byte[] shuffled = BitShuffle.shuffle(original); } }

The program will crash with the following error (or similar):

Exception in thread "main" java.lang.NegativeArraySizeException: -2147483648 at org.xerial.snappy.BitShuffle.shuffle(BitShuffle.java:108) at org.example.Main.main(Main.java:11)

Summary Due to unchecked multiplications, an integer overflow may occur, causing an unrecoverable fatal error. Impact Denial of Service Description The function [compress(char[] input)](https://github.com/xerial/snappy-java/blob/05c39b2ca9b5b7b39611529cc302d3d796329611/src/main/java/org/xerial/snappy/Snappy.java#L169) in the file Snappy.java receives an array of characters and compresses it. It does so by multiplying the length by 2 and passing it to the rawCompress function.

java public static byte[] compress(char[] input) throws IOException { return rawCompress(input, input.length 2); // char uses 2 bytes }

Since the length is not tested, the multiplication by two can cause an integer overflow and become negative. The rawCompress function then uses the received length and passes it to the natively compiled maxCompressedLength function, using the returned value to allocate a byte array.

java public static byte[] rawCompress(Object data, int byteSize) throws IOException { byte[] buf = new byte[Snappy.maxCompressedLength(byteSize)]; int compressedByteSize = impl.rawCompress(data, 0, byteSize, buf, 0); byte[] result = new byte[compressedByteSize]; System.arraycopy(buf, 0, result, 0, compressedByteSize); return result; }

Since the maxCompressedLength function treats the length as an unsigned integer, it doesn’t care that it is negative, and it returns a valid value, which is casted to a signed integer by the Java engine. If the result is negative, a “java.lang.NegativeArraySizeException” exception will be raised while trying to allocate the array “buf”. On the other side, if the result is positive, the “buf” array will successfully be allocated, but its size might be too small to use for the compression, causing a fatal Access Violation error. The same issue exists also when using the “compress” functions that receive double, float, int, long and short, each using a different multiplier that may cause the same issue. The issue most likely won’t occur when using a byte array, since creating a byte array of size 0x80000000 (or any other negative value) is impossible in the first place.

Steps To Reproduce Compile and run the following code:

java package org.example; import org.xerial.snappy.Snappy;

import java.io.;

public class Main {

public static void main(String[] args) throws IOException { char[] uncompressed = new char[0x40000000]; byte[] compressed = Snappy.compress(uncompressed); } }

The program will crash, creating crashdumps and showing the following error (or similar):

A fatal error has been detected by the Java Runtime Environment: EXCEPTIONACCESSVIOLATION (0xc0000005) at pc=0x0000000063a01c20, pid=21164, tid=508 .......

Alternatively - compile and run the following code:

java package org.example; import org.xerial.snappy.Snappy;

import java.io.;

public class Main {

public static void main(String[] args) throws IOException { char[] uncompressed = new char[0x3fffffff]; byte[] compressed = Snappy.compress(uncompressed); } }

The program will crash with the following error (or similar), since the maxCompressedLength returns a value that is interpreted as negative by java:

Exception in thread "main" java.lang.NegativeArraySizeException: -1789569677 at org.xerial.snappy.Snappy.rawCompress(Snappy.java:425) at org.xerial.snappy.Snappy.compress(Snappy.java:172) at org.example.Main.main(Main.java:10)

A flaw was found in the Linux kernel. It is possible to overflow a perfevent's readsize, causing an out-of-bounds write in perfreadgroup(). The check meant to prevent such an overflow in perfeventvalidatesize() does not account for groups of events with mixed readformat values. The flaw can be triggered with events created with PERFFORMATGROUP or events added with PERFFORMATGROUP after some preconditions.

The bug was introduced around fa8c269353d5 ("perf/core: Invert perfreadgroup() loops"). Fixes: a723968c0ed3 ("perf: Fix u16 overflows").

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=382c27f4ed28f803b1f1473ac2d8db0afc795a1b

An out-of-bounds memory read flaw was found in receiveencryptedstandard in fs/smb/client/smb2ops.c in the SMB Client sub-component in the Linux Kernel. This issue occurs due to integer underflow on the memcpy length, leading to a denial of service.

A use-after-free vulnerability in the Linux kernel's netfilter: nftables component can be exploited to achieve local privilege escalation.

The nftverdictinit() function allows positive values as drop error within the hook verdict, and hence the nfhookslow() function can cause a double free vulnerability when NFDROP is issued with a drop error which resembles NFACCEPT.

We recommend upgrading past commit f342de4e2f33e0e39165d8639387aa6c19dff660.

GnuPG Libgcrypt could allow a remote attacker to obtain sensitive information, caused by improper handling of ElGamal encryption. By using side-channel attack techniques against mpipowm, and the window size, an attacker could exploit this vulnerability to obtain sensitive information, and use this information to launch further attacks against the affected system.

An integer overflow in the RFC3164 parser in One Identity syslog-ng 3.0 through 3.37 allows remote attackers to cause a Denial of Service via crafted syslog input that is mishandled by the tcp or network function. syslog-ng Premium Edition 7.0.30 and syslog-ng Store Box 6.10.0 are also affected.

A race condition was found in the GSM 0710 tty multiplexor (drivers/tty/ngsm.c) in the Linux kernel. The flaw occurs when two threads execute the GSMIOCSETCONF ioctl on the same tty file descriptor with the gsm line discipline enabled and leads to a use-after-free on a struct gsmdlci while restarting the gsm mux. A local unprivileged user could use this vulnerability to escalate their privileges on the system.

ZDI Security Advisory: https://www.zerodayinitiative.com/advisories/ZDI-CAN-20527

Upstream fix: https://github.com/torvalds/linux/commit/3c4f8333b582487a2d1e02171f1465531cde53e3

A vulnerability was found in libpcre in PCRE before 8.43 allows a subject buffer over-read in JIT when UTF is disabled, and \X or \R has more than one fixed quantifier, a related issue to CVE-2019-20454.

References: https://bugs.gentoo.org/717920 https://www.pcre.org/original/changelog.txt

Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.3 through 1.25.0.

Users are recommended to upgrade to version 1.26.0 which fixes the issue.

Summary Due to use of an unchecked chunk length, an unrecoverable fatal error can occur. Impact Denial of Service Description The code in the function hasNextChunk in the file SnappyInputStream.java checks if a given stream has more chunks to read. It does that by attempting to read 4 bytes. If it wasn’t possible to read the 4 bytes, the function returns false. Otherwise, if 4 bytes were available, the code treats them as the length of the next chunk.

java int readBytes = readNext(header, 0, 4); if (readBytes < 4) { return false; }

int chunkSize = SnappyOutputStream.readInt(header, 0); if (chunkSize == SnappyCodec.MAGICHEADERHEAD) { ......... }

// extend the compressed data buffer size if (compressed == null || chunkSize > compressed.length) { compressed = new byte[chunkSize]; }

In the case that the “compressed” variable is null, a byte array is allocated with the size given by the input data. Since the code doesn’t test the legality of the “chunkSize” variable, it is possible to pass a negative number (such as 0xFFFFFFFF which is -1), which will cause the code to raise a “java.lang.NegativeArraySizeException” exception. A worse case would happen when passing a huge positive value (such as 0x7FFFFFFF), which would raise the fatal “java.lang.OutOfMemoryError” error.

Steps To Reproduce Compile and run the following code:

java package org.example; import org.xerial.snappy.SnappyInputStream;

import java.io.;

public class Main {

public static void main(String[] args) throws IOException { byte[] data = {-126, 'S', 'N', 'A', 'P', 'P', 'Y', 0, 0, 0, 0, 0, 0, 0, 0, 0,(byte) 0x7f, (byte) 0xff, (byte) 0xff, (byte) 0xff}; SnappyInputStream in = new SnappyInputStream(new ByteArrayInputStream(data)); byte[] out = new byte[50]; try { in.read(out); } catch (Exception ignored) {

} } }

The program will crash with the following error (or similar), even though there is a catch clause, since “OutOfMemoryError” does not get caught by catching the “Exception” class:

Exception in thread "main" java.lang.OutOfMemoryError: Requested array size exceeds VM limit at org.xerial.snappy.SnappyInputStream.hasNextChunk(SnappyInputStream.java:422) at org.xerial.snappy.SnappyInputStream.read(SnappyInputStream.java:167) at java.base/java.io.InputStream.read(InputStream.java:217) at org.example.Main.main(Main.java:12)

Alternatively - compile and run the following code:

java package org.example; import org.xerial.snappy.SnappyInputStream;

import java.io.;

public class Main {

public static void main(String[] args) throws IOException { byte[] data = {-126, 'S', 'N', 'A', 'P', 'P', 'Y', 0, 0, 0, 0, 0, 0, 0, 0, 0,(byte) 0xff, (byte) 0xff, (byte) 0xff, (byte) 0xff}; SnappyInputStream in = new SnappyInputStream(new ByteArrayInputStream(data)); byte[] out = new byte[50]; in.read(out); } }

The program will crash with the following error (or similar):

Exception in thread "main" java.lang.NegativeArraySizeException: -1 at org.xerial.snappy.SnappyInputStream.hasNextChunk(SnappyInputStream.java:422) at org.xerial.snappy.SnappyInputStream.read(SnappyInputStream.java:167) at java.base/java.io.InputStream.read(InputStream.java:217) at org.example.Main.main(Main.java:12)

It is important to note that these examples were written by using a flow that is generally used by developers, and can be seen for example in the Apache project “flume”: https://github.com/apache/flume/blob/f9dbb2de255d59e35e3668a5c6c66a268a055207/flume-ng-channels/flume-file-channel/src/main/java/org/apache/flume/channel/file/Serialization.java#L278. Since they used try-catch, the “NegativeArraySizeException” exception won’t harm their users, but the “OutOfMemoryError” error can.

An issue was discovered in flsetgeneveopt in net/sched/clsflower.c in the Linux kernel before 6.3.7. It allows an out-of-bounds write in the flower classifier code via TCAFLOWERKEYENCOPTSGENEVE packets. This may result in denial of service or privilege escalation.

A regression in the fix for bug 66512 in Apache Tomcat 11.0.0-M5, 10.1.8, 9.0.74 and 8.5.88 meant that, if a response did not include any HTTP headers no AJP SENDHEADERS message would be sent for the response which in turn meant that at least one AJP proxy (modproxyajp) would use the response headers from the previous request leading to an information leak.

Allocation of Resources Without Limits or Throttling vulnerability in Apache Software Foundation Apache Struts.This issue affects Apache Struts: through 2.5.30, through 6.1.2.

Upgrade to Struts 2.5.31 or 6.1.2.1 or greater

Accounts. A privacy issue was addressed with improved private data redaction for log entries.

A memory leak flaw was found in Apache Tomcat, where an HTTP upgrade connection does not release for WebSocket connections once the WebSocket connection is closed. If a sufficient number of such requests are made, an OutOfMemoryError occurs, leading to a denial of service. The highest threat from this vulnerability is to system availability.

A flaw was found in the way nettle's RSA decryption functions handled specially crafted ciphertext. An attacker could use this flaw to provide a manipulated ciphertext leading to application crash and denial of service.

A flaw was found in libdnf's signature verification functionality in versions before 0.60.1. This flaw allows an attacker to achieve code execution if they can alter the header information of an RPM package and then trick a user or system into installing it. The highest risk of this vulnerability is to confidentiality, integrity, as well as system availability.

Integer Overflow or Wraparound vulnerability in openEuler kernel on Linux (filesystem modules) allows Forced Integer Overflow.This issue affects openEuler kernel: from 4.19.90 before 4.19.90-2401.3, from 5.10.0-60.18.0 before 5.10.0-183.0.0.

The encodeinvalidchars function in util/url.py in the urllib3 library 1.25.2 through 1.25.7 for Python allows a denial of service (CPU consumption) because of an inefficient algorithm. The percentencodings array contains all matches of percent encodings. It is not deduplicated. For a URL of length N, the size of percentencodings may be up to O(N). The next step (normalize existing percent-encoded bytes) also takes up to O(N) for each step, so the total time is O(N^2). If percentencodings were deduplicated, the time to compute encodeinvalidchars would be O(kN), where k is at most 484 ((10+62)^2).

A flaw was found in the Java logging library Apache Log4j in version 1.x . This allows a remote attacker to execute code on the server if the deployed application is configured to use JMSAppender.

In 1.x you will find that there are two places where lookups are done - that is JMSAppender.java:207 and JMSAppender.java:222 - if you set TopicBindingName or TopicConnectionFactoryBindingName to something that JNDI can handle - for example "ldap://host:port/a" JNDI will do exactly the same thing it does for 2.x - so 1.x is vulnerable, just attack vector is "safer" as it depends on configuration rather than user input

This flaw in Log4j 2.x is tracked via CVE-2021-44228

An issue was discovered in drivers/usb/storage/eneub6250.c for the ENE UB6250 reader driver in the Linux kernel before 6.2.5. An object could potentially extend beyond the end of an allocation.

In the Linux kernel before 6.4.5 drivers/gpu/drm/drmatomic.c has a use-after-free during a race condition between a nonblocking atomic commit and a driver unload.

In the Linux kernel before 6.4.12 amdgpucswaitallfences in drivers/gpu/drm/amd/amdgpu/amdgpucs.c has a fence use-after-free.

A flaw was found in curl. This flaw lies in the --ssl-reqd option or related settings in libcurl. Users specify this flag to upgrade to TLS when communicating with either IMAP, POP3 or a FTP server. An attacker controlling such servers could return a crafted response which could lead to curl client continue its operation without TLS encryption leading to data being transmitted in clear text over the network. The highest threat from this vulnerability is to data confidentiality.

IBM QRadar SIEM 7.5 through 7.5.0 UP13 could allow an authenticated user to escalate their privileges via a misconfigured cronjob due to execution with unnecessary privileges.

IBM QRadar SIEM 7.5 through 7.5.0 Update Pack 13 Independent Fix 02 is vulnerable to privilege escalation due to improper privilege assignment to an update script.

An issue was discovered in function libssh2packetadd in libssh2 1.10.0 allows attackers to access out of bounds memory.

Impact The HTML Cleaner in lxml.html lets certain crafted script content pass through, as well as script content in SVG files embedded using data URIs.

Users that employ the HTML cleaner in a security relevant context should upgrade to lxml 4.6.5.

Patches The issue has been resolved in lxml 4.6.5.

Workarounds None.

References The issues are tracked under the report IDs GHSL-2021-1037 and GHSL-2021-1038.