hitoshura25/cvefixes huggingface dataset:
CVE-2013-7455 (Other, published 2016-05-07T10:59Z)
Description: value: Double free vulnerability in the DefaultICCintents function in cmscnvrt.c in liblcms2 in Little CMS 2.x before 2.6 allows remote attackers to execute arbitrary code via a malformed ICC profile that triggers an error in the default intent handler.
Severity: HIGH (CVSS v3 base score: 9.8)
Weakness: NVD-CWE-Other \u2014 Other
NVD is only using a subset of CWE for mapping instead of the entire CWE, and the weakness type is not covered by that subset.
Repository: https://github.com/mm2/Little-CMS
Files changed:
ChangeLog
src/cmscnvrt.c
Commit message: Fix a double free on error recovering


Vulnerable code:
    cmsPipelineFree(Lut);

Fixed code:

Fixed a double free in recovering from a previous error in default intent handler.


        Lut = NULL;
    if (Lut != NULL) cmsPipelineFree(Lut);
CVE-2016-10165 (C, published 2017-02-03T19:59Z)
Description: value: The Type_MLU_Read function in cmstypes.c in Little CMS (aka lcms2) allows remote attackers to obtain sensitive information or cause a denial of service via an image with a crafted ICC profile, which triggers an out-of-bounds heap read.
Severity: MEDIUM (CVSS v3 base score: 7.1)
Weakness: CWE-125 \u2014 Out-of-bounds Read
The product reads data past the end, or before the beginning, of the intended buffer.
Repository: https://github.com/mm2/Little-CMS
Files changed:
src/cmstypes.c
Commit message: Added an extra check to MLU bounds

Thanks to Ibrahim el-sayed for spotting the bug


Vulnerable code:

Fixed code:
        if ((Offset + Len) > SizeOfTag + 8) goto Error;
CVE-2018-16435 (Other, published 2018-09-04T00:29Z)
Description: value: Little CMS (aka Little Color Management System) 2.9 has an integer overflow in the AllocateDataSet function in cmscgats.c, leading to a heap-based buffer overflow in the SetData function via a crafted file in the second argument to cmsIT8LoadFromFile.
Severity: MEDIUM (CVSS v3 base score: 5.5)
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/mm2/Little-CMS
Files changed:
Projects/VC2017/jpegicc/jpegicc.vcxproj
Projects/VC2017/lcms2_DLL/lcms2_DLL.vcxproj
Projects/VC2017/lcms2_static/lcms2_static.vcxproj
Projects/VC2017/linkicc/linkicc.vcxproj
Projects/VC2017/psicc/psicc.vcxproj
Projects/VC2017/testbed/testbed.vcxproj
Projects/VC2017/tiffdiff/tiffdiff.vcxproj
Projects/VC2017/tifficc/tifficc.vcxproj
Projects/VC2017/transicc/transicc.vcxproj
src/cmscgats.c
Commit message: Upgrade Visual studio 2017 15.8

- Upgrade to 15.8
- Add check on CGATS memory allocation (thanks to Quang Nguyen for
pointing out this)


Vulnerable code:
    <WindowsTargetPlatformVersion>8.1</WindowsTargetPlatformVersion>
    <WindowsTargetPlatformVersion>8.1</WindowsTargetPlatformVersion>
    <WindowsTargetPlatformVersion>8.1</WindowsTargetPlatformVersion>
    <WindowsTargetPlatformVersion>8.1</WindowsTargetPlatformVersion>
    <WindowsTargetPlatformVersion>8.1</WindowsTargetPlatformVersion>
    <WindowsTargetPlatformVersion>8.1</WindowsTargetPlatformVersion>
    <WindowsTargetPlatformVersion>8.1</WindowsTargetPlatformVersion>
//  Copyright (c) 1998-2017 Marti Maria Saguer
    t-> Data = (char**)AllocChunk (it8, ((cmsUInt32Number) t->nSamples + 1) * ((cmsUInt32Number) t->nPatches + 1) *sizeof (char*));
    if (t->Data == NULL) {
        SynError(it8, "AllocateDataSet: Unable to allocate data array");

Fixed code:
    <WindowsTargetPlatformVersion>10.0.17134.0</WindowsTargetPlatformVersion>
    <WindowsTargetPlatformVersion>10.0.17134.0</WindowsTargetPlatformVersion>
    <WindowsTargetPlatformVersion>10.0.17134.0</WindowsTargetPlatformVersion>
    <WindowsTargetPlatformVersion>10.0.17134.0</WindowsTargetPlatformVersion>
    <WindowsTargetPlatformVersion>10.0.17134.0</WindowsTargetPlatformVersion>
    <WindowsTargetPlatformVersion>10.0.17134.0</WindowsTargetPlatformVersion>
    <WindowsTargetPlatformVersion>10.0.17134.0</WindowsTargetPlatformVersion>
    <WindowsTargetPlatformVersion>10.0.17134.0</WindowsTargetPlatformVersion>
    <WindowsTargetPlatformVersion>10.0.17134.0</WindowsTargetPlatformVersion>
//  Copyright (c) 1998-2018 Marti Maria Saguer
    if (t -> nSamples < 0 || t->nSamples > 0x7ffe || t->nPatches < 0 || t->nPatches > 0x7ffe)
    {
        SynError(it8, "AllocateDataSet: too much data");
    }
    else {
        t->Data = (char**)AllocChunk(it8, ((cmsUInt32Number)t->nSamples + 1) * ((cmsUInt32Number)t->nPatches + 1) * sizeof(char*));
        if (t->Data == NULL) {
            SynError(it8, "AllocateDataSet: Unable to allocate data array");
        }
CVE-2017-7412 (Other, published 2017-04-04T00:59Z)
Description: value: NixOS 17.03 before 17.03.887 has a world-writable Docker socket, which allows local users to gain privileges by executing docker commands.
Severity: HIGH (CVSS v3 base score: 7.8)
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/NixOS/nixpkgs
Files changed:
nixos/modules/virtualisation/docker.nix
Commit message: docker: fix socket permissions

Docker socket is world writable. This means any user on the system is
able to invoke docker command. (Which is equal to having a root access
to the machine.)

This commit makes socket group-writable and owned by docker group.

Inspired by
https://github.com/docker/docker/blob/master/contrib/init/systemd/docker.socket


Vulnerable code:
      systemd.sockets.docker.socketConfig.ListenStream = cfg.listenOptions;

Fixed code:

      systemd.sockets.docker = {
        description = "Docker Socket for the API";
        wantedBy = [ "sockets.target" ];
        socketConfig = {
          ListenStream = cfg.listenOptions;
          SocketMode = "0660";
          SocketUser = "root";
          SocketGroup = "docker";
        };
      };
CVE-2015-2141 (C++, published 2015-07-01T14:59Z)
Description: value: The InvertibleRWFunction::CalculateInverse function in rw.cpp in libcrypt++ 5.6.2 does not properly blind private key operations for the Rabin-Williams digital signature algorithm, which allows remote attackers to obtain private keys via a timing attack.
Severity: MEDIUM (CVSS v3 base score: )
Weakness: CWE-200 \u2014 Exposure of Sensitive Information to an Unauthorized Actor
The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
Repository: https://github.com/weidai11/cryptopp
Files changed:
rw.cpp
Commit message: Fix for CVE-2015-2141. Thanks to Evgeny Sidorov for reporting. Squaring to satisfy Jacobi requirements suggested by JPM.


Vulnerable code:
	do {	// do this in a loop for people using small numbers for testing

Fixed code:

	// do this in a loop for people using small numbers for testing
	do {
		// Fix for CVE-2015-2141. Thanks to Evgeny Sidorov for reporting.
		// Squaring to satisfy Jacobi requirements suggested by JPM.
		r = modn.Square(r);
CVE-2014-3158 (C, published 2014-11-15T21:59Z)
Description: value: Integer overflow in the getword function in options.c in pppd in Paul's PPP Package (ppp) before 2.4.7 allows attackers to "access privileged options" via a long word in an options file, which triggers a heap-based buffer overflow that "[corrupts] security-relevant variables."
Severity: HIGH (CVSS v3 base score: )
Weakness: CWE-119 \u2014 Improper Restriction of Operations within the Bounds of a Memory Buffer
The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.
Repository: https://github.com/paulusmack/ppp
Files changed:
pppd/options.c
Commit message: pppd: Eliminate potential integer overflow in option parsing

When we are reading in a word from an options file, we maintain a count
of the length we have seen so far in 'len', which is an int.  When len
exceeds MAXWORDLEN - 1 (i.e. 1023) we cease storing characters in the
buffer but we continue to increment len.  Since len is an int, it will
wrap around to -2147483648 after it reaches 2147483647.  At that point
our test of (len < MAXWORDLEN-1) will succeed and we will start writing
characters to memory again.

This may enable an attacker to overwrite the heap and thereby corrupt
security-relevant variables.  For this reason it has been assigned a
CVE identifier, CVE-2014-3158.

This fixes the bug by ceasing to increment len once it reaches MAXWORDLEN.

Reported-by: Lee Campbell <leecam@google.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>


Vulnerable code:
	    if (len < MAXWORDLEN-1)
	    ++len;
	if (len < MAXWORDLEN-1)
	++len;

Fixed code:
	    if (len < MAXWORDLEN) {
		++len;
	    }
	if (len < MAXWORDLEN) {
	    ++len;
	}
CVE-2020-8597 (C, published 2020-02-03T23:15Z)
Description: value: eap.c in pppd in ppp 2.4.2 through 2.4.8 has an rhostname buffer overflow in the eap_request and eap_response functions.
Severity: HIGH (CVSS v3 base score: 9.8)
Weakness: CWE-120 \u2014 Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
The product copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow.
Repository: https://github.com/paulusmack/ppp
Files changed:
pppd/eap.c
Commit message: pppd: Fix bounds check in EAP code

Given that we have just checked vallen < len, it can never be the case
that vallen >= len + sizeof(rhostname).  This fixes the check so we
actually avoid overflowing the rhostname array.

Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>


Vulnerable code:
		if (vallen >= len + sizeof (rhostname)) {
		if (vallen >= len + sizeof (rhostname)) {

Fixed code:
		if (len - vallen >= sizeof (rhostname)) {
		if (len - vallen >= sizeof (rhostname)) {
CVE-2024-22779 (Other, published 2024-02-02T02:15Z)
Description: value: Directory Traversal vulnerability in Kihron ServerRPExposer v.1.0.2 and before allows a remote attacker to execute arbitrary code via the loadServerPack in ServerResourcePackProviderMixin.java.
Severity: nan (CVSS v3 base score: 9.8)
Weakness: CWE-22 \u2014 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.
Repository: https://github.com/Kihron/ServerRPExposer
Files changed:
gradle.properties
src/main/java/com/kihron/serverrpexposer/mixins/ServerResourcePackProviderMixin.java
Commit message: - bumped version to 1.0.3
- fixed vulnerability allowing servers to add files into arbitrary folders (unlikely but possible)


Vulnerable code:
mod_version=1.0.2

Fixed code:
mod_version=1.0.3
                    if (!entryDestination.getCanonicalPath().startsWith(path.toRealPath() + "/")) continue;
CVE-2022-29255 (Python, published 2022-06-09T09:15Z)
Description: value: Vyper is a Pythonic Smart Contract Language for the ethereum virtual machine. In versions prior to 0.3.4 when a calling an external contract with no return value, the contract address (including side effects) could be evaluated twice. This may result in incorrect outcomes for contracts. This issue has been addressed in v0.3.4.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-670 \u2014 Always-Incorrect Control Flow Implementation
The code contains a control flow path that does not reflect the algorithm that the path is intended to implement, leading to incorrect behavior any time this path is navigated.
Repository: https://github.com/vyperlang/vyper
Files changed:
tests/parser/features/external_contracts/test_external_contract_calls.py
vyper/codegen/external_call.py
Commit message: Merge pull request from GHSA-4v9q-cgpw-cf38

in external call codegen, when `extcodesize` is called on the target
address, the IR for evaluating the target address can be evaluated
twice. this can result in any side effects (embedded in the evaluation
of the target address) being executed twice.

Vulnerable code:
def ir_for_external_call(call_expr, context):
    from vyper.codegen.expr import Expr  # TODO rethink this circular import

    contract_address = Expr.parse_value_expr(call_expr.func.value, context)
    call_kwargs = _parse_kwargs(call_expr, context)
    args_ir = [Expr(x, context).ir_node for x in call_expr.args]

    assert isinstance(contract_address.typ, InterfaceType)


Fixed code:


def test_contract_address_evaluation(get_contract):
    callee_code = """
# implements: Foo

interface Counter:
    def increment_counter(): nonpayable

@external
def foo():
    pass

@external
def bar() -> address:
    Counter(msg.sender).increment_counter()
    return self
    """
    code = """
# implements: Counter

interface Foo:
    def foo(): nonpayable
    def bar() -> address: nonpayable

counter: uint256

@external
def increment_counter():
    self.counter += 1

@external
def do_stuff(f: Foo) -> uint256:
    Foo(f.bar()).foo()
    return self.counter
    """

    c1 = get_contract(code)
    c2 = get_contract(callee_code)

    assert c1.do_stuff(c2.address) == 1
def _external_call_helper(contract_address, args_ir, call_kwargs, call_expr, context):


def ir_for_external_call(call_expr, context):
    from vyper.codegen.expr import Expr  # TODO rethink this circular import

    contract_address = Expr.parse_value_expr(call_expr.func.value, context)
    assert isinstance(contract_address.typ, InterfaceType)
    args_ir = [Expr(x, context).ir_node for x in call_expr.args]
    call_kwargs = _parse_kwargs(call_expr, context)

    with contract_address.cache_when_complex("external_contract") as (b1, contract_address):
        return b1.resolve(
            _external_call_helper(contract_address, args_ir, call_kwargs, call_expr, context)
        )
CVE-2023-30629 (Python, published 2023-04-24T22:15Z)
Description: value: Vyper is a Pythonic Smart Contract Language for the ethereum virtual machine. In versions 0.3.1 through 0.3.7, the Vyper compiler generates the wrong bytecode. Any contract that uses the `raw_call` with `revert_on_failure=False` and `max_outsize=0` receives the wrong response from `raw_call`. Depending on the memory garbage, the result can be either `True` or `False`. A patch is available and, as of time of publication, anticipated to be part of Vyper 0.3.8. As a workaround, one may always put  `max_outsize>0`.
Severity: nan (CVSS v3 base score: 7.5)
Weakness: CWE-670 \u2014 Always-Incorrect Control Flow Implementation
The code contains a control flow path that does not reflect the algorithm that the path is intended to implement, leading to incorrect behavior any time this path is navigated.
Repository: https://github.com/vyperlang/vyper
Files changed:
tests/parser/functions/test_raw_call.py
vyper/builtins/functions.py
Commit message: Merge pull request from GHSA-w9g2-3w7p-72g9

it was getting tagged as a pointer instead of a stack value during
codegen

Vulnerable code:
            if revert_on_failure:
                typ = None
                ret_ir = check_external_call(call_ir)
            else:
                typ = bool_ty
                ret_ir = call_ir
        return IRnode.from_list(ret_ir, typ=typ, location=MEMORY)

Fixed code:

# (fail2 fails because of staticcall)


# test max_outsize not set case
@external
@nonpayable
def baz(_addr: address, should_raise: bool) -> uint256:
    success: bool = True
    success = raw_call(
        _addr,
        _abi_encode(should_raise, method_id=method_id("fail1(bool)")),
        revert_on_failure=False,
    )
    assert success == (not should_raise)
    return 3
    assert caller.baz(target.address, True) == 3
    assert caller.baz(target.address, False) == 3
                # check the call success flag, and store returndata in memory
                return IRnode.from_list(ret_ir, typ=typ, location=MEMORY)
                # return an IR tuple of call success flag and returndata pointer
                return IRnode.from_list(ret_ir, typ=typ)

        # max_outsize is 0.

        if not revert_on_failure:
            # return call flag as stack item
            typ = bool_ty
            return IRnode.from_list(call_ir, typ=typ)
            # check the call success flag and don't return anything
            ret_ir = check_external_call(call_ir)
            return IRnode.from_list(ret_ir, typ=None)
        raise CompilerPanic("unreachable!")
CVE-2023-32058 (Python, published 2023-05-11T21:15Z)
Description: value: Vyper is a Pythonic smart contract language for the Ethereum virtual machine. Prior to version 0.3.8, due to missing overflow check for loop variables, by assigning the iterator of a loop to a variable, it is possible to overflow the type of the latter. The issue seems to happen only in loops of type `for i in range(a, a + N)` as in loops of type `for i in range(start, stop)` and `for i in range(stop)`, the compiler is able to raise a `TypeMismatch` when trying to overflow the variable. The problem has been patched in version 0.3.8.
Severity: nan (CVSS v3 base score: 7.5)
Weakness: CWE-190 \u2014 Integer Overflow or Wraparound
The product performs a calculation that can
         produce an integer overflow or wraparound when the logic
         assumes that the resulting value will always be larger than
         the original value. This occurs when an integer value is
         incremented to a value that is too large to store in the
         associated representation. When this occurs, the value may
         become a very small or negative number.
Repository: https://github.com/vyperlang/vyper
Files changed:
tests/parser/features/iteration/test_for_range.py
vyper/codegen/stmt.py
Commit message: Merge pull request from GHSA-6r8q-pfpv-7cgj

for loops of the form `for i in range(x, x+N)`, the range of the
iterator is not checked, leading to potential overflow. the following
example demonstrates the potential for overflow:

```
@external
def test() -> uint16:
    x:uint8 = 255
    a:uint8 = 0
    for i in range(x, x+2):
        a = i
    return convert(a,uint16)  # returns 256
```

this commit fixes the issue by adding a range check before entering the
loop body.

Vulnerable code:

Fixed code:
# test that we can get to the upper range of an integer
@pytest.mark.parametrize("typ", ["uint8", "int128", "uint256"])
def test_for_range_edge(get_contract, typ):
    code = f"""
@external
def test():
    found: bool = False
    x: {typ} = max_value({typ})
    for i in range(x, x + 1):
        if i == max_value({typ}):
            found = True

    assert found

    found = False
    x = max_value({typ}) - 1
    for i in range(x, x + 2):
        if i == max_value({typ}):
            found = True

    assert found
    """
    c = get_contract(code)
    c.test()


@pytest.mark.parametrize("typ", ["uint8", "int128", "uint256"])
def test_for_range_oob_check(get_contract, assert_tx_failed, typ):
    code = f"""
@external
def test():
    x: {typ} = max_value({typ})
    for i in range(x, x+2):
        pass
    """
    c = get_contract(code)
    assert_tx_failed(lambda: c.test())


    clamp,
            _, hi = start.typ.int_bounds
            start = clamp("le", start, hi + 1 - rounds)
CVE-2023-37902 (Python, published 2023-07-25T21:15Z)
Description: value: Vyper is a Pythonic programming language that targets the Ethereum Virtual Machine (EVM). Prior to version 0.3.10, the ecrecover precompile does not fill the output buffer if the signature does not verify. However, the ecrecover builtin will still return whatever is at memory location 0. This means that the if the compiler has been convinced to write to the 0 memory location with specially crafted data (generally, this can happen with a hashmap access or immutable read) just before the ecrecover, a signature check might pass on an invalid signature. Version 0.3.10 contains a patch for this issue.
Severity: nan (CVSS v3 base score: 5.3)
Weakness: CWE-252 \u2014 Unchecked Return Value
The product does not check the return value from a method or function, which can prevent it from detecting unexpected states and conditions.
Repository: https://github.com/vyperlang/vyper
Files changed:
tests/parser/functions/test_ecrecover.py
vyper/builtins/functions.py
Commit message: Merge pull request from GHSA-f5x6-7qgp-jhf3



Vulnerable code:
        placeholder_node = IRnode.from_list(
            context.new_internal_variable(BytesT(128)), typ=BytesT(128), location=MEMORY
        )
                ["mstore", placeholder_node, args[0]],
                ["mstore", ["add", placeholder_node, 32], args[1]],
                ["mstore", ["add", placeholder_node, 64], args[2]],
                ["mstore", ["add", placeholder_node, 96], args[3]],
                [
                    "pop",
                    [
                        "staticcall",
                        ["gas"],
                        1,
                        placeholder_node,
                        128,
                        MemoryPositions.FREE_VAR_SPACE,
                        32,
                    ],
                ],
                ["mload", MemoryPositions.FREE_VAR_SPACE],

Fixed code:


def test_invalid_signature(get_contract):
    code = """
dummies: HashMap[address, HashMap[address, uint256]]

@external
def test_ecrecover(hash: bytes32, v: uint8, r: uint256) -> address:
    # read from hashmap to put garbage in 0 memory location
    s: uint256 = self.dummies[msg.sender][msg.sender]
    return ecrecover(hash, v, r, s)
    """
    c = get_contract(code)
    hash_ = bytes(i for i in range(32))
    v = 0  # invalid v! ecrecover precompile will not write to output buffer
    r = 0
    # note web3.py decoding of 0x000..00 address is None.
    assert c.test_ecrecover(hash_, v, r) is None
        input_buf = context.new_internal_variable(get_type_for_exact_size(128))
        output_buf = MemoryPositions.FREE_VAR_SPACE
                # clear output memory first, ecrecover can return 0 bytes
                ["mstore", output_buf, 0],
                ["mstore", input_buf, args[0]],
                ["mstore", input_buf + 32, args[1]],
                ["mstore", input_buf + 64, args[2]],
                ["mstore", input_buf + 96, args[3]],
                ["staticcall", "gas", 1, input_buf, 128, output_buf, 32],
                ["mload", output_buf],