hitoshura25/cvefixes huggingface dataset:
CVE-2022-24823 (Java, published 2022-05-06T12:15Z)
Description: value: Netty is an open-source, asynchronous event-driven network application framework. The package `io.netty:netty-codec-http` prior to version 4.1.77.Final contains an insufficient fix for CVE-2021-21290. When Netty's multipart decoders are used local information disclosure can occur via the local system temporary directory if temporary storing uploads on the disk is enabled. This only impacts applications running on Java version 6 and lower. Additionally, this vulnerability impacts code running on Unix-like systems, and very old versions of Mac OSX and Windows as they all share the system temporary directory between all users. Version 4.1.77.Final contains a patch for this vulnerability. As a workaround, specify one's own `java.io.tmpdir` when starting the JVM or use DefaultHttpDataFactory.setBaseDir(...) to set the directory to something that is only readable by the current user.
Severity: LOW (CVSS v3 base score: 5.5)
Weakness: CWE-378 \u2014 Creation of Temporary File With Insecure Permissions
Opening temporary files without appropriate measures or controls can leave the file, its contents and any function that it impacts vulnerable to attack.
Repository: https://github.com/netty/netty
Files changed:
common/src/main/java/io/netty/util/internal/PlatformDependent.java
Commit message: Merge pull request from GHSA-269q-hmxg-m83q

* Correctly modify permission for temporary files when using Java 6 in all cases

Motivation:

[GHSA-5mcr-gq6c-3hq2](https://github.com/netty/netty/security/advisories/GHSA-5mcr-gq6c-3hq2) did not correctly fix all cases for temprory files when running on java 6.

Modifications:

- Add correctly adjust perms in all cases
- Add logging if adjusting of permissions fails

Result:

Fixes https://github.com/netty/netty/security/advisories/GHSA-269q-hmxg-m83q

* Throw on failure

Vulnerable code:
            return File.createTempFile(prefix, suffix);
        File file = File.createTempFile(prefix, suffix, directory);
        file.setReadable(false, false);
        file.setReadable(true, true);

Fixed code:
        final File file;
            file = File.createTempFile(prefix, suffix);
        } else {
            file = File.createTempFile(prefix, suffix, directory);

        if (!file.setReadable(false, false)) {
            throw new IOException("Failed to set permissions on temporary file " + file);
        }
        if (!file.setReadable(true, true)) {
            throw new IOException("Failed to set permissions on temporary file " + file);
        }
CVE-2022-24823 (Java, published 2022-05-06T12:15Z)
Description: value: Netty is an open-source, asynchronous event-driven network application framework. The package `io.netty:netty-codec-http` prior to version 4.1.77.Final contains an insufficient fix for CVE-2021-21290. When Netty's multipart decoders are used local information disclosure can occur via the local system temporary directory if temporary storing uploads on the disk is enabled. This only impacts applications running on Java version 6 and lower. Additionally, this vulnerability impacts code running on Unix-like systems, and very old versions of Mac OSX and Windows as they all share the system temporary directory between all users. Version 4.1.77.Final contains a patch for this vulnerability. As a workaround, specify one's own `java.io.tmpdir` when starting the JVM or use DefaultHttpDataFactory.setBaseDir(...) to set the directory to something that is only readable by the current user.
Severity: LOW (CVSS v3 base score: 5.5)
Weakness: CWE-379 \u2014 Creation of Temporary File in Directory with Insecure Permissions
The product creates a temporary file in a directory whose permissions allow unintended actors to determine the file's existence or otherwise access that file.
Repository: https://github.com/netty/netty
Files changed:
common/src/main/java/io/netty/util/internal/PlatformDependent.java
Commit message: Merge pull request from GHSA-269q-hmxg-m83q

* Correctly modify permission for temporary files when using Java 6 in all cases

Motivation:

[GHSA-5mcr-gq6c-3hq2](https://github.com/netty/netty/security/advisories/GHSA-5mcr-gq6c-3hq2) did not correctly fix all cases for temprory files when running on java 6.

Modifications:

- Add correctly adjust perms in all cases
- Add logging if adjusting of permissions fails

Result:

Fixes https://github.com/netty/netty/security/advisories/GHSA-269q-hmxg-m83q

* Throw on failure

Vulnerable code:
            return File.createTempFile(prefix, suffix);
        File file = File.createTempFile(prefix, suffix, directory);
        file.setReadable(false, false);
        file.setReadable(true, true);

Fixed code:
        final File file;
            file = File.createTempFile(prefix, suffix);
        } else {
            file = File.createTempFile(prefix, suffix, directory);

        if (!file.setReadable(false, false)) {
            throw new IOException("Failed to set permissions on temporary file " + file);
        }
        if (!file.setReadable(true, true)) {
            throw new IOException("Failed to set permissions on temporary file " + file);
        }
CVE-2022-24823 (Java, published 2022-05-06T12:15Z)
Description: value: Netty is an open-source, asynchronous event-driven network application framework. The package `io.netty:netty-codec-http` prior to version 4.1.77.Final contains an insufficient fix for CVE-2021-21290. When Netty's multipart decoders are used local information disclosure can occur via the local system temporary directory if temporary storing uploads on the disk is enabled. This only impacts applications running on Java version 6 and lower. Additionally, this vulnerability impacts code running on Unix-like systems, and very old versions of Mac OSX and Windows as they all share the system temporary directory between all users. Version 4.1.77.Final contains a patch for this vulnerability. As a workaround, specify one's own `java.io.tmpdir` when starting the JVM or use DefaultHttpDataFactory.setBaseDir(...) to set the directory to something that is only readable by the current user.
Severity: LOW (CVSS v3 base score: 5.5)
Weakness: CWE-668 \u2014 Exposure of Resource to Wrong Sphere
The product exposes a resource to the wrong control sphere, providing unintended actors with inappropriate access to the resource.
Repository: https://github.com/netty/netty
Files changed:
common/src/main/java/io/netty/util/internal/PlatformDependent.java
Commit message: Merge pull request from GHSA-269q-hmxg-m83q

* Correctly modify permission for temporary files when using Java 6 in all cases

Motivation:

[GHSA-5mcr-gq6c-3hq2](https://github.com/netty/netty/security/advisories/GHSA-5mcr-gq6c-3hq2) did not correctly fix all cases for temprory files when running on java 6.

Modifications:

- Add correctly adjust perms in all cases
- Add logging if adjusting of permissions fails

Result:

Fixes https://github.com/netty/netty/security/advisories/GHSA-269q-hmxg-m83q

* Throw on failure

Vulnerable code:
            return File.createTempFile(prefix, suffix);
        File file = File.createTempFile(prefix, suffix, directory);
        file.setReadable(false, false);
        file.setReadable(true, true);

Fixed code:
        final File file;
            file = File.createTempFile(prefix, suffix);
        } else {
            file = File.createTempFile(prefix, suffix, directory);

        if (!file.setReadable(false, false)) {
            throw new IOException("Failed to set permissions on temporary file " + file);
        }
        if (!file.setReadable(true, true)) {
            throw new IOException("Failed to set permissions on temporary file " + file);
        }
CVE-2022-41915 (Java, published 2022-12-13T07:15Z)
Description: value: Netty project is an event-driven asynchronous network application framework. Starting in version 4.1.83.Final and prior to 4.1.86.Final, when calling `DefaultHttpHeadesr.set` with an _iterator_ of values, header value validation was not performed, allowing malicious header values in the iterator to perform HTTP Response Splitting. This issue has been patched in version 4.1.86.Final. Integrators can work around the issue by changing the `DefaultHttpHeaders.set(CharSequence, Iterator<?>)` call, into a `remove()` call, and call `add()` in a loop over the iterator of values.
Severity: nan (CVSS v3 base score: 6.5)
Weakness: CWE-113 \u2014 Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting')
The product receives data from an HTTP agent/component (e.g., web server, proxy, browser, etc.), but it does not neutralize or incorrectly neutralizes CR and LF characters before the data is included in outgoing HTTP headers.
Repository: https://github.com/netty/netty
Files changed:
codec-http/src/test/java/io/netty/handler/codec/http/DefaultHttpHeadersTest.java
codec/src/main/java/io/netty/handler/codec/DefaultHeaders.java
Commit message: Merge pull request from GHSA-hh82-3pmq-7frp

Motivation:
The setObject methods that took arrays and iterators as arguments provided a way to bypass value validation.

Modification:
Add the missing value validation checks.

Result:
It is no longer possibel to bypass value validation in DefaultHeaders based implementations, including DefaultHttpHeaders.

Vulnerable code:
import java.util.Arrays;
            add0(h, i, name, fromObject(name, v));
            add0(h, i, name, fromObject(name, v));

Fixed code:
import java.util.Collections;
    private static final CharSequence ILLEGAL_VALUE = "testHeader\r\nContent-Length:45\r\n\r\n";
    @Test
    public void setCharSequenceValidatesValue() {
        final DefaultHttpHeaders headers = newDefaultDefaultHttpHeaders();
        assertThrows(IllegalArgumentException.class, new Executable() {
            @Override
            public void execute() throws Throwable {
                headers.set(HEADER_NAME, ILLEGAL_VALUE);
            }
        });
    }

    @Test
    public void setIterableValidatesValue() {
        final DefaultHttpHeaders headers = newDefaultDefaultHttpHeaders();
        assertThrows(IllegalArgumentException.class, new Executable() {
            @Override
            public void execute() throws Throwable {
                headers.set(HEADER_NAME, Collections.singleton(ILLEGAL_VALUE));
            }
        });
    }

            V converted = fromObject(name, v);
            validateValue(valueValidator, name, converted);
            add0(h, i, name, converted);
            V converted = fromObject(name, v);
            validateValue(valueValidator, name, converted);
            add0(h, i, name, converted);
CVE-2022-41915 (Java, published 2022-12-13T07:15Z)
Description: value: Netty project is an event-driven asynchronous network application framework. Starting in version 4.1.83.Final and prior to 4.1.86.Final, when calling `DefaultHttpHeadesr.set` with an _iterator_ of values, header value validation was not performed, allowing malicious header values in the iterator to perform HTTP Response Splitting. This issue has been patched in version 4.1.86.Final. Integrators can work around the issue by changing the `DefaultHttpHeaders.set(CharSequence, Iterator<?>)` call, into a `remove()` call, and call `add()` in a loop over the iterator of values.
Severity: nan (CVSS v3 base score: 6.5)
Weakness: CWE-436 \u2014 Interpretation Conflict
Product A handles inputs or steps differently than Product B, which causes A to perform incorrect actions based on its perception of B's state.
Repository: https://github.com/netty/netty
Files changed:
codec-http/src/test/java/io/netty/handler/codec/http/DefaultHttpHeadersTest.java
codec/src/main/java/io/netty/handler/codec/DefaultHeaders.java
Commit message: Merge pull request from GHSA-hh82-3pmq-7frp

Motivation:
The setObject methods that took arrays and iterators as arguments provided a way to bypass value validation.

Modification:
Add the missing value validation checks.

Result:
It is no longer possibel to bypass value validation in DefaultHeaders based implementations, including DefaultHttpHeaders.

Vulnerable code:
import java.util.Arrays;
            add0(h, i, name, fromObject(name, v));
            add0(h, i, name, fromObject(name, v));

Fixed code:
import java.util.Collections;
    private static final CharSequence ILLEGAL_VALUE = "testHeader\r\nContent-Length:45\r\n\r\n";
    @Test
    public void setCharSequenceValidatesValue() {
        final DefaultHttpHeaders headers = newDefaultDefaultHttpHeaders();
        assertThrows(IllegalArgumentException.class, new Executable() {
            @Override
            public void execute() throws Throwable {
                headers.set(HEADER_NAME, ILLEGAL_VALUE);
            }
        });
    }

    @Test
    public void setIterableValidatesValue() {
        final DefaultHttpHeaders headers = newDefaultDefaultHttpHeaders();
        assertThrows(IllegalArgumentException.class, new Executable() {
            @Override
            public void execute() throws Throwable {
                headers.set(HEADER_NAME, Collections.singleton(ILLEGAL_VALUE));
            }
        });
    }

            V converted = fromObject(name, v);
            validateValue(valueValidator, name, converted);
            add0(h, i, name, converted);
            V converted = fromObject(name, v);
            validateValue(valueValidator, name, converted);
            add0(h, i, name, converted);
CVE-2018-25017 (C++, published 2021-07-01T03:15Z)
Description: value: RawSpeed (aka librawspeed) 3.1 has a heap-based buffer overflow in TableLookUp::setTable.
Severity: HIGH (CVSS v3 base score: 9.8)
Weakness: CWE-787 \u2014 Out-of-bounds Write
The product writes data past the end, or before the beginning, of the intended buffer.
Repository: https://github.com/darktable-org/rawspeed
Files changed:
src/librawspeed/common/TableLookUp.cpp
Commit message: TableLookUp::setTable(): do actually check that the LUT is <2^16


Vulnerable code:

Fixed code:
  if (nfilled >= 65536)
    ThrowRDE("Table lookup with %i entries is unsupported", nfilled);
CVE-2017-15377 (C, published 2017-10-23T08:29Z)
Description: value: In Suricata before 4.x, it was possible to trigger lots of redundant checks on the content of crafted network traffic with a certain signature, because of DetectEngineContentInspection in detect-engine-content-inspection.c. The search engine doesn't stop when it should after no match is found; instead, it stops only upon reaching inspection-recursion-limit (3000 by default).
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: NVD-CWE-noinfo \u2014 Insufficient Information
There is insufficient information about the issue to classify it; details are unkown or unspecified.
Repository: https://github.com/OISF/suricata
Files changed:
src/detect-engine-content-inspection.c
Commit message: detect: avoid needless recursive scanning

Don't recursively inspect a detect list if the recursion
doesn't increase chance of success.


Vulnerable code:
/* Copyright (C) 2007-2011 Open Information Security Foundation
                if (!(cd->flags & DETECT_CONTENT_RELATIVE_NEXT)) {
                    SCLogDebug("no relative match coming up, so this is a match");
                    goto match;
                }
                /* bail out if we have no next match. Technically this is an
                 * error, as the current cd has the DETECT_CONTENT_RELATIVE_NEXT
                 * flag set. */
                    goto no_match;
                if (det_ctx->discontinue_matching)

Fixed code:
/* Copyright (C) 2007-2017 Open Information Security Foundation
                if ((cd->flags & (DETECT_CONTENT_DISTANCE|DETECT_CONTENT_WITHIN)) == 0) {
                    /* independent match from previous matches, so failure is fatal */
                    det_ctx->discontinue_matching = 1;
                }

                /* if this is the last match we're done */
                    goto match;
                SCLogDebug("no match for 'next sm'");
                if (det_ctx->discontinue_matching) {
                    SCLogDebug("'next sm' said to discontinue this right now");
                }

                /* no match and no reason to look for another instance */
                if ((cd->flags & DETECT_CONTENT_RELATIVE_NEXT) == 0) {
                    SCLogDebug("'next sm' does not depend on me, so we can give up");
                    det_ctx->discontinue_matching = 1;
                    goto no_match;
                }

                SCLogDebug("'next sm' depends on me %p, lets see what we can do (flags %u)", cd, cd->flags);
CVE-2019-18625 (C, published 2020-01-06T21:15Z)
Description: value: An issue was discovered in Suricata 5.0.0. It was possible to bypass/evade any tcp based signature by faking a closed TCP session using an evil server. After the TCP SYN packet, it is possible to inject a RST ACK and a FIN ACK packet with a bad TCP Timestamp option. The client will ignore the RST ACK and the FIN ACK packets because of the bad TCP Timestamp option. Both linux and windows client are ignoring the injected packets.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: NVD-CWE-noinfo \u2014 Insufficient Information
There is insufficient information about the issue to classify it; details are unkown or unspecified.
Repository: https://github.com/OISF/suricata
Files changed:
src/stream-tcp.c
Commit message: stream: fix SYN_SENT RST/FIN injection

RST injection during the SYN_SENT state could trick Suricata into marking
a session as CLOSED. The way this was done is: using invalid TSECR value
in RST+ACK packet. The ACK was needed to force Linux into considering the
TSECR value and compare it to the TSVAL from the SYN packet.

The second works only against Windows. The client would not use a TSVAL
but the RST packet would. Windows will reject this, but Suricata considered
the RST valid and triggered the CLOSED logic.

This patch addresses both. When the SYN packet used timestamp support
the timestamp of incoming packet is validated. Otherwise, packet responding
should not have a timestamp.

Bug #3286

Reported-by: Nicolas Adba


Vulnerable code:

Fixed code:
/** \internal
 *  \brief detect timestamp anomalies when processing responses to the
 *         SYN packet.
 *  \retval true packet is ok
 *  \retval false packet is bad
 */
static inline bool StateSynSentValidateTimestamp(TcpSession *ssn, Packet *p)
{
    /* we only care about evil server here, so skip TS packets */
    if (PKT_IS_TOSERVER(p) || !(TCP_HAS_TS(p))) {
        return true;
    }

    TcpStream *receiver_stream = &ssn->client;
    uint32_t ts_echo = TCP_GET_TSECR(p);
    if ((receiver_stream->flags & STREAMTCP_STREAM_FLAG_TIMESTAMP) != 0) {
        if (receiver_stream->last_ts != 0 && ts_echo != 0 &&
            ts_echo != receiver_stream->last_ts)
        {
            SCLogDebug("ssn %p: BAD TSECR echo %u recv %u", ssn,
                    ts_echo, receiver_stream->last_ts);
            return false;
        }
    } else {
        if (receiver_stream->last_ts == 0 && ts_echo != 0) {
            SCLogDebug("ssn %p: BAD TSECR echo %u recv %u", ssn,
                    ts_echo, receiver_stream->last_ts);
            return false;
        }
    }
    return true;
}

    /* check for bad responses */
    if (StateSynSentValidateTimestamp(ssn, p) == false)
        return -1;
CVE-2019-18792 (C, published 2020-01-06T18:15Z)
Description: value: An issue was discovered in Suricata 5.0.0. It is possible to bypass/evade any tcp based signature by overlapping a TCP segment with a fake FIN packet. The fake FIN packet is injected just before the PUSH ACK packet we want to bypass. The PUSH ACK packet (containing the data) will be ignored by Suricata because it overlaps the FIN packet (the sequence and ack number are identical in the two packets). The client will ignore the fake FIN packet because the ACK flag is not set. Both linux and windows clients are ignoring the injected packet.
Severity: MEDIUM (CVSS v3 base score: 9.1)
Weakness: CWE-436 \u2014 Interpretation Conflict
Product A handles inputs or steps differently than Product B, which causes A to perform incorrect actions based on its perception of B's state.
Repository: https://github.com/OISF/suricata
Files changed:
src/stream-tcp.c
Commit message: stream: reject broken ACK packets

Fix evasion posibility by rejecting packets with a broken ACK field.
These packets have a non-0 ACK field, but do not have a ACK flag set.

Bug #3324.

Reported-by: Nicolas Adba


Vulnerable code:
    tcph.th_ack = htonl(11);

Fixed code:
        goto error;
    tcph.th_ack = 0;
CVE-2024-23835 (Rust, published 2024-02-26T16:27Z)
Description: value: Suricata is a network Intrusion Detection System, Intrusion Prevention System and Network Security Monitoring engine.  Prior to version 7.0.3, excessive memory use during pgsql parsing could lead to OOM-related crashes.  This vulnerability is patched in 7.0.3.  As workaround, users can disable the pgsql app layer parser.
Severity: nan (CVSS v3 base score: )
Weakness: NVD-CWE-noinfo \u2014 Insufficient Information
There is insufficient information about the issue to classify it; details are unkown or unspecified.
Repository: https://github.com/OISF/suricata
Files changed:
rust/src/pgsql/parser.rs
Commit message: pgsql: parse only PDU when type is unknown

A next PDU may already be in the slice to parse.
Do not skip its parsing, ie do not use rest, but take just
the length of the pdu


Vulnerable code:
use nom7::combinator::{all_consuming, cond, eof, map_parser, opt, peek, rest, verify};
                    let (i, payload) = rest(i)?;
                        identifier: pseudo_header.0,
                        length: pseudo_header.1,
            payload: bad_buf.to_vec(),

Fixed code:
use nom7::combinator::{all_consuming, cond, eof, map_parser, opt, peek, verify};
                    let (i, identifier) = be_u8(i)?;
                    let (i, length) = verify(be_u32, |&x| x > PGSQL_LENGTH_FIELD)(i)?;
                    let (i, payload) = take(length - PGSQL_LENGTH_FIELD)(i)?;
                        identifier,
                        length,
            payload: bad_buf[5..].to_vec(),
CVE-2024-23835 (Rust, published 2024-02-26T16:27Z)
Description: value: Suricata is a network Intrusion Detection System, Intrusion Prevention System and Network Security Monitoring engine.  Prior to version 7.0.3, excessive memory use during pgsql parsing could lead to OOM-related crashes.  This vulnerability is patched in 7.0.3.  As workaround, users can disable the pgsql app layer parser.
Severity: nan (CVSS v3 base score: )
Weakness: NVD-CWE-noinfo \u2014 Insufficient Information
There is insufficient information about the issue to classify it; details are unkown or unspecified.
Repository: https://github.com/OISF/suricata
Files changed:
rust/src/pgsql/parser.rs
Commit message: pgsql: parse auth message within its bound

If the next PDU is already in the slice next, do not use it and
restrict ourselves to the length of this PDU.
Avoids overconsumption of memory by quadratic complexity, when
having many small PDUS in one big chunk being parsed

Ticket: #6411


Vulnerable code:
    let (i, payload) = peek(rest)(i)?;
                                payload: payload.to_vec(),
                                payload: payload.to_vec(),
                                payload: payload.to_vec(),
                    let (b, sasl_challenge) = rest(i)?;
                                    payload: sasl_challenge.to_vec(),
                    let (i, signature) = take(length - 8)(i)?;
                    Ok((i, PgsqlBEMessage::AuthenticationSASLFinal(
                                    payload: signature.to_vec(),

Fixed code:
                                payload: b.to_vec(),
                                payload: b.to_vec(),
                                payload: b.to_vec(),
                                    payload: b.to_vec(),
                    Ok((b, PgsqlBEMessage::AuthenticationSASLFinal(
                                    payload: b.to_vec(),