A flaw was found in the way the ClassFileParser class implementation in the Hotspot component of OpenJDK performed validation of inner class index values. A specially-crafted class file could cause a Java virtual machine to crash when loaded.

A flaw was found in the way the BMPImageReader class implementation in the ImageIO component of OpenJDK handled memory allocations when processing uncompressed BMP images. A specially-crafted BMP image with a small size could cause a Java application to allocate an excessive amount of memory and possibly terminate on out-of-memory condition.

A flaw was found in the SSL logger implementation in the JSSE component of OpenJDK. A malicious client could cause a Java application acting as TLS server to raise an unexpected exception during TLS handshake.

A flaw was found in the way the Keytool component of OpenJDK handled X.509 certificates with validity period ending too far in the future, after year 9999. When such certificates were imported into a keystore, they could cause corruption of the keystore.

A flaw was found in the way the RTFReader class implementation in the Swing component of OpenJDK handled style keyword parameters. A specially crafted Rich Text Format (RTF) file could cause a Java application using RTFReader to allocate an excessive ammount of memory and possibly terminate on out-of-memory condition.

An inifinte loop flaw was found in the HttpsServer class implementation in the JSSE component of OpenJDK. A remote attacker could possibly use this flaw to cause a Java application implementing HTTPS server functionality to loop during the TLS session closing and consume an excessive amount of CPU time.

A flaw was found in the way the RTFParser class implementation in the Swing component of OpenJDK handled memory allocations. A specially crafted Rich Text Format (RTF) file could cause a Java application using RTFParser to allocate an excessive amount of memory and possibly terminate on out-of-memory condition.

Impact Accepting the value of various Text options of the Datepicker widget from untrusted sources may execute untrusted code. For example, initializing the datepicker in the following way: js $( "#datepicker" ).datepicker( { showButtonPanel: true, showOn: "both", closeText: "<script>doEvilThing( 'closeText XSS' )</script>", currentText: "<script>doEvilThing( 'currentText XSS' )</script>", prevText: "<script>doEvilThing( 'prevText XSS' )</script>", nextText: "<script>doEvilThing( 'nextText XSS' )</script>", buttonText: "<script>doEvilThing( 'buttonText XSS' )</script>", appendText: "<script>doEvilThing( 'appendText XSS' )</script>", } ); will call doEvilThing with 6 different parameters coming from all Text options.

Patches The issue is fixed in jQuery UI 1.13.0. The values passed to various Text options are now always treated as pure text, not HTML.

Workarounds A workaround is to not accept the value of the Text options from untrusted sources.

For more information If you have any questions or comments about this advisory, search for a relevant issue in the jQuery UI repo. If you don't find an answer, open a new issue.

Impact Accepting the value of the of option of the .position() util from untrusted sources may execute untrusted code. For example, invoking the following code: js $( "#element" ).position( { my: "left top", at: "right bottom", of: "<img onerror='doEvilThing()' src='/404' />", collision: "none" } ); will call the doEvilThing() function.

Patches The issue is fixed in jQuery UI 1.13.0. Any string value passed to the of option is now treated as a CSS selector.

Workarounds A workaround is to not accept the value of the of option from untrusted sources.

For more information If you have any questions or comments about this advisory, search for a relevant issue in the jQuery UI repo. If you don't find an answer, open a new issue.

Impact Accepting the value of the altField option of the Datepicker widget from untrusted sources may execute untrusted code. For example, initializing the datepicker in the following way: js $( "#datepicker" ).datepicker( { altField: "<img onerror='doEvilThing()' src='/404' />", } ); will call the doEvilThing function.

Patches The issue is fixed in jQuery UI 1.13.0. Any string value passed to the altField option is now treated as a CSS selector.

Workarounds A workaround is to not accept the value of the altField option from untrusted sources.

For more information If you have any questions or comments about this advisory, search for a relevant issue in the jQuery UI repo. If you don't find an answer, open a new issue.

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

A vulnerability was found in libpcre in PCRE before 8.44 allows an integer overflow via a large number after a (?C substring.

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

Apache Log4j is vulnerable to a man-in-the-middle attack, caused by improper certificate validation with host mismatch in the SMTP appender. An attacker could exploit this vulnerability to launch a man-in-the-middle attack and gain access to the communication channel between endpoints to obtain sensitive information or further compromise the system.

Allocation of Resources Without Limits or Throttling vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.21 before 1.26.

Users are recommended to upgrade to version 1.26, which fixes the issue.

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.

GNU ncurses could allow a remote attacker to obtain sensitive information, caused by a heap-based buffer over-read in the ncfindentry function in tinfo/comphash.c in the terminfo library. By persuading a victim to open a specially-crafted file, an attacker could exploit this vulnerability to obtain sensitive information.

GNU ncurses could allow a remote attacker to obtain sensitive information, caused by a heap-based buffer over-read in the fmtentry function in tinfo/comphash.c in the terminfo library. By persuading a victim to open a specially-crafted file, an attacker could exploit this vulnerability to obtain sensitive information.

Last updated 4 February 2025

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.