hitoshura25/cvefixes huggingface dataset:
CVE-2022-46149 (Other, published 2022-11-30T17:15Z)
Description: value: Cap'n Proto is a data interchange format and remote procedure call (RPC) system. Cap'n Proro prior to versions 0.7.1, 0.8.1, 0.9.2, and 0.10.3, as well as versions of Cap'n Proto's Rust implementation prior to 0.13.7, 0.14.11, and 0.15.2 are vulnerable to out-of-bounds read due to logic error handling list-of-list. This issue may lead someone to remotely segfault a peer by sending it a malicious message, if the victim performs certain actions on a list-of-pointer type. Exfiltration of memory is possible if the victim performs additional certain actions on a list-of-pointer type. To be vulnerable, an application must perform a specific sequence of actions, described in the GitHub Security Advisory. The bug is present in inlined code, therefore the fix will require rebuilding dependent applications. Cap'n Proto has C++ fixes available in versions 0.7.1, 0.8.1, 0.9.2, and 0.10.3. The `capnp` Rust crate has fixes available in versions 0.13.7, 0.14.11, and 0.15.2.
Severity: nan (CVSS v3 base score: 5.4)
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/capnproto/capnproto
Files changed:
c++/src/capnp/layout.c++
c++/src/capnp/layout.h
Commit message: Apply data offset for list-of-pointers at access time rather than ListReader creation time.

Baking this offset into `ptr` reduced ops needed at access time but made the interpretation of `ptr` inconsistent depending on what type of list was expected.


Vulnerable code:
            // We expected a list of pointers but got a list of structs.  Assuming the first field
            // in the struct is the pointer we were looking for, we want to munge the pointer to
            // point at the first element's pointer section.
            ptr += tag->structRef.dataSize.get();
      ptr + upgradeBound<uint64_t>(index) * step / BITS_PER_BYTE), nestingLimit);

Fixed code:
  // If the list elements have data sections we need to skip those. Note that for pointers to be
  // present at all (which already must be true if we get here), then `structDataSize` must be a
  // whole number of words, so we don't have to worry about unaligned reads here.
  auto offset = structDataSize / BITS_PER_BYTE;
      ptr + offset + upgradeBound<uint64_t>(index) * step / BITS_PER_BYTE), nestingLimit);
CVE-2023-48230 (Other, published 2023-11-21T21:15Z)
Description: value: Cap'n Proto is a data interchange format and capability-based RPC system. In versions 1.0 and 1.0.1, when using the KJ HTTP library with WebSocket compression enabled, a buffer underrun can be caused by a remote peer. The underrun always writes a constant value that is not attacker-controlled, likely resulting in a crash, enabling a remote denial-of-service attack. Most Cap'n Proto and KJ users are unlikely to have this functionality enabled and so unlikely to be affected. Maintainers suspect only the Cloudflare Workers Runtime is affected.

If KJ HTTP is used with WebSocket compression enabled, a malicious peer may be able to cause a buffer underrun on a heap-allocated buffer. KJ HTTP is an optional library bundled with Cap'n Proto, but is not directly used by Cap'n Proto. WebSocket compression is disabled by default. It must be enabled via a setting passed to the KJ HTTP library via `HttpClientSettings` or `HttpServerSettings`. The bytes written out-of-bounds are always a specific constant 4-byte string `{ 0x00, 0x00, 0xFF, 0xFF }`. Because this string is not controlled by the attacker, maintainers believe it is unlikely that remote code execution is possible. However, it cannot be ruled out. This functionality first appeared in Cap'n Proto 1.0. Previous versions are not affected.

This issue is fixed in Cap'n Proto 1.0.1.1.
Severity: nan (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/capnproto/capnproto
Files changed:
c++/src/kj/compat/http.c++
Commit message: Fix inconsistent decision about whether a WebSocket message is compressed.

When processing the header, we decide whether the mesasge is compressed based on the presence of the appropriate flag in the header. However, after receiving the whole message, we were expecting it to be compressed based only on whether the session had negotiated compression upfront. With this patch we only rely on the bits in the header (and throw if the header says it is compressed, but we didn't negotiate compression.)


Vulnerable code:
        [this,opcode,payloadTarget,payloadLen,mask,isFin,maxSize,originalMaxSize,message=kj::mv(message)]() mutable
          KJ_IF_SOME(config, compressionConfig) {
          KJ_IF_SOME(config, compressionConfig) {

Fixed code:
    bool isCompressed = false;
        isCompressed = true;
        [this,opcode,payloadTarget,payloadLen,mask,isFin,maxSize,originalMaxSize,
         isCompressed,message=kj::mv(message)]() mutable
          if (isCompressed) {
            auto& config = KJ_ASSERT_NONNULL(compressionConfig);
            KJ_ASSERT(message.size() >= 4);
          if (isCompressed) {
            auto& config = KJ_ASSERT_NONNULL(compressionConfig);
            KJ_ASSERT(message.size() >= 4);
CVE-2021-32724 (Unknown, published 2021-09-09T21:15Z)
Description: value: check-spelling is a github action which provides CI spell checking. In affected versions and for a repository with the [check-spelling action](https://github.com/marketplace/actions/check-spelling) enabled that triggers on `pull_request_target` (or `schedule`), an attacker can send a crafted Pull Request that causes a `GITHUB_TOKEN` to be exposed. With the `GITHUB_TOKEN`, it's possible to push commits to the repository bypassing standard approval processes. Commits to the repository could then steal any/all secrets available to the repository. As a workaround users may can either: [Disable the workflow](https://docs.github.com/en/actions/managing-workflow-runs/disabling-and-enabling-a-workflow) until you've fixed all branches or Set repository to [Allow specific actions](https://docs.github.com/en/github/administering-a-repository/managing-repository-settings/disabling-or-limiting-github-actions-for-a-repository#allowing-specific-actions-to-run). check-spelling isn't a verified creator and it certainly won't be anytime soon. You could then explicitly add other actions that your repository uses. Set repository [Workflow permissions](https://docs.github.com/en/github/administering-a-repository/managing-repository-settings/disabling-or-limiting-github-actions-for-a-repository#setting-the-permissions-of-the-github_token-for-your-repository) to `Read repository contents permission`. Workflows using `check-spelling/check-spelling@main` will get the fix automatically. Workflows using a pinned sha or tagged version will need to change the affected workflows for all repository branches to the latest version. Users can verify who and which Pull Requests have been running the action by looking up the spelling.yml action in the Actions tab of their repositories, e.g., https://github.com/check-spelling/check-spelling/actions/workflows/spelling.yml - you can filter PRs by adding ?query=event%3Apull_request_target, e.g., https://github.com/check-spelling/check-spelling/actions/workflows/spelling.yml?query=event%3Apull_request_target.
Severity: MEDIUM (CVSS v3 base score: 9.9)
Weakness: CWE-532 \u2014 Insertion of Sensitive Information into Log File
Information written to log files can be of a sensitive nature and give valuable guidance to an attacker or expose sensitive user information.
Repository: https://github.com/check-spelling/check-spelling
Files changed:
Commit message: Merge pull request from GHSA-g86g-chm8-7r2p

File handling

Vulnerable code:

Fixed code:
CVE-2017-6430 (C, published 2017-03-15T15:59Z)
Description: value: The compile_tree function in ef_compiler.c in the Etterfilter utility in Ettercap 0.8.2 and earlier allows remote attackers to cause a denial of service (out-of-bounds read) via a crafted filter.
Severity: MEDIUM (CVSS v3 base score: 5.5)
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/LocutusOfBorg/ettercap
Files changed:
utils/etterfilter/ef_compiler.c
utils/etterfilter/ef_main.c
utils/etterfilter/ef_output.c
Commit message: Exit gracefully in case of corrupted filters (Closes issue #782)


Vulnerable code:
   BUG_IF(tree_root == NULL);
   if (write_output() != E_SUCCESS)
      FATAL_ERROR("Cannot write output file (%s)", EF_GBL_OPTIONS->output_file);

Fixed code:
   // invalid file
   if (tree_root == NULL)
      return 0;
   int ret_value = 0;
   ret_value = write_output();
   if (ret_value == -E_NOTHANDLED)
      FATAL_ERROR("Cannot write output file (%s): the filter is not correctly handled.", EF_GBL_OPTIONS->output_file);
   else if (ret_value == -E_INVALID)
      FATAL_ERROR("Cannot write output file (%s): the filter format is not correct. ", EF_GBL_OPTIONS->output_file);

   if (ninst == 0)
      return -E_INVALID;
CVE-2018-12588 (Other, published 2018-06-19T21:29Z)
Description: value: Cross-site scripting (XSS) vulnerability in templates/frontend/pages/searchResults.tpl in Public Knowledge Project (PKP) Open Monograph Press (OMP) v1.2.0 through 3.1.1-2 before 3.1.1-3 allows remote attackers to inject arbitrary web script or HTML via the catalog.noTitlesSearch parameter (aka the Search field).
Severity: MEDIUM (CVSS v3 base score: 6.1)
Weakness: CWE-79 \u2014 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.
Repository: https://github.com/pkp/omp
Files changed:
templates/frontend/pages/searchResults.tpl
Commit message: pkp/pkp-lib#3805 Add missing escaping to catalog.noTitlesSearch


Vulnerable code:
			{translate key="catalog.noTitlesSearch" searchQuery=$searchQuery}

Fixed code:
			{translate key="catalog.noTitlesSearch" searchQuery=$searchQuery|escape}
CVE-2015-4335 (C, published 2015-06-09T14:59Z)
Description: value: Redis before 2.8.21 and 3.x before 3.0.2 allows remote attackers to execute arbitrary Lua bytecode via the eval command.
Severity: HIGH (CVSS v3 base score: )
Weakness: CWE-17 \u2014 DEPRECATED: Code
This entry has been deprecated.  It was originally used for organizing the Development View (CWE-699) and some other views, but it introduced unnecessary complexity and depth to the resulting tree.
Repository: https://github.com/antirez/redis
Files changed:
deps/lua/src/ldo.c
Commit message: disable loading lua bytecode


Vulnerable code:
  tf = ((c == LUA_SIGNATURE[0]) ? luaU_undump : luaY_parser)(L, p->z,

Fixed code:
  tf = (luaY_parser)(L, p->z,
CVE-2018-11218 (C, published 2018-06-17T17:29Z)
Description: value: Memory Corruption was discovered in the cmsgpack library in the Lua subsystem in Redis before 3.2.12, 4.x before 4.0.10, and 5.x before 5.0 RC2 because of stack-based buffer overflows.
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/antirez/redis
Files changed:
deps/lua/src/lua_cmsgpack.c
Commit message: Security: more cmsgpack fixes by @soloestoy.

@soloestoy sent me this additional fixes, after searching for similar
problems to the one reported in mp_pack(). I'm committing the changes
because it was not possible during to make a public PR to protect Redis
users and give Redis providers some time to patch their systems.


Vulnerable code:

Fixed code:
    luaL_checkstack(L, 1, "in function mp_encode_lua_table_as_array");
    luaL_checkstack(L, 3, "in function mp_encode_lua_table_as_map");
        luaL_checkstack(L, 1, "in function mp_check");
    luaL_checkstack(L, 1, "in function mp_decode_to_lua_array");

        luaL_checkstack(L, 1, "in function mp_unpack_full");
CVE-2018-11218 (C, published 2018-06-17T17:29Z)
Description: value: Memory Corruption was discovered in the cmsgpack library in the Lua subsystem in Redis before 3.2.12, 4.x before 4.0.10, and 5.x before 5.0 RC2 because of stack-based buffer overflows.
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/antirez/redis
Files changed:
deps/lua/src/lua_cmsgpack.c
Commit message: Security: fix Lua cmsgpack library stack overflow.

During an auditing effort, the Apple Vulnerability Research team discovered
a critical Redis security issue affecting the Lua scripting part of Redis.

-- Description of the problem

Several years ago I merged a pull request including many small changes at
the Lua MsgPack library (that originally I authored myself). The Pull
Request entered Redis in commit 90b6337c1, in 2014.
Unfortunately one of the changes included a variadic Lua function that
lacked the check for the available Lua C stack. As a result, calling the
"pack" MsgPack library function with a large number of arguments, results
into pushing into the Lua C stack a number of new values proportional to
the number of arguments the function was called with. The pushed values,
moreover, are controlled by untrusted user input.

This in turn causes stack smashing which we believe to be exploitable,
while not very deterministic, but it is likely that an exploit could be
created targeting specific versions of Redis executables. However at its
minimum the issue results in a DoS, crashing the Redis server.

-- Versions affected

Versions greater or equal to Redis 2.8.18 are affected.

-- Reproducing

Reproduce with this (based on the original reproduction script by
Apple security team):

https://gist.github.com/antirez/82445fcbea6d9b19f97014cc6cc79f8a

-- Verification of the fix

The fix was tested in the following way:

1) I checked that the problem is no longer observable running the trigger.
2) The Lua code was analyzed to understand the stack semantics, and that
actually enough stack is allocated in all the cases of mp_pack() calls.
3) The mp_pack() function was modified in order to show exactly what items
in the stack were being set, to make sure that there is no silent overflow
even after the fix.

-- Credits

Thank you to the Apple team and to the other persons that helped me
checking the patch and coordinating this communication.


Vulnerable code:

Fixed code:
    if (!lua_checkstack(L, nargs))
        return luaL_argerror(L, 0, "Too many arguments for MessagePack pack.");
CVE-2018-11219 (C, published 2018-06-17T17:29Z)
Description: value: An Integer Overflow issue was discovered in the struct library in the Lua subsystem in Redis before 3.2.12, 4.x before 4.0.10, and 5.x before 5.0 RC2, leading to a failure of bounds checking.
Severity: HIGH (CVSS v3 base score: 9.8)
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/antirez/redis
Files changed:
deps/lua/src/lua_struct.c
Commit message: Security: fix Lua struct package offset handling.

After the first fix to the struct package I found another similar
problem, which is fixed by this patch. It could be reproduced easily by
running the following script:

    return struct.unpack('f', "xxxxxxxxxxxxx",-3)

The above will access bytes before the 'data' pointer.


Vulnerable code:
  size_t pos = luaL_optinteger(L, 3, 1) - 1;
    luaL_argcheck(L, pos+size <= ld, 2, "data string too short");

Fixed code:
  size_t pos = luaL_optinteger(L, 3, 1);
  luaL_argcheck(L, pos > 0, 3, "offset must be 1 or greater");
  pos--; /* Lua indexes are 1-based, but here we want 0-based for C
          * pointer math. */
    luaL_argcheck(L, size <= ld && pos <= ld - size,
                   2, "data string too short");
CVE-2018-12453 (C, published 2018-06-16T17:29Z)
Description: value: Type confusion in the xgroupCommand function in t_stream.c in redis-server in Redis before 5.0 allows remote attackers to cause denial-of-service via an XGROUP command in which the key is not a stream.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-704 \u2014 Incorrect Type Conversion or Cast
The product does not correctly convert an object, resource, or structure from one type to a different type.
Repository: https://github.com/antirez/redis
Files changed:
src/t_stream.c
Commit message: Abort in XGROUP if the key is not a stream


Vulnerable code:
        if (o == NULL) return;

Fixed code:
        if (o == NULL || checkType(c,o,OBJ_STREAM)) return;
CVE-2020-14147 (C, published 2020-06-15T18:15Z)
Description: value: An integer overflow in the getnum function in lua_struct.c in Redis before 6.0.3 allows context-dependent attackers with permission to run Lua code in a Redis session to cause a denial of service (memory corruption and application crash) or possibly bypass intended sandbox restrictions via a large number, which triggers a stack-based buffer overflow. NOTE: this issue exists because of a CVE-2015-8080 regression.
Severity: MEDIUM (CVSS v3 base score: 7.7)
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/antirez/redis
Files changed:
deps/lua/src/lua_struct.c
Commit message: [FIX] revisit CVE-2015-8080 vulnerability


Vulnerable code:
static int getnum (const char **fmt, int df) {
    case 'c': return getnum(fmt, 1);
      int sz = getnum(fmt, sizeof(int));
      int a = getnum(fmt, MAXALIGN);

Fixed code:
static int getnum (lua_State *L, const char **fmt, int df) {
      if (a > (INT_MAX / 10) || a * 10 > (INT_MAX - (**fmt - '0')))
        luaL_error(L, "integral size overflow");
    case 'c': return getnum(L, fmt, 1);
      int sz = getnum(L, fmt, sizeof(int));
      int a = getnum(L, fmt, MAXALIGN);
CVE-2020-14147 (C, published 2020-06-15T18:15Z)
Description: value: An integer overflow in the getnum function in lua_struct.c in Redis before 6.0.3 allows context-dependent attackers with permission to run Lua code in a Redis session to cause a denial of service (memory corruption and application crash) or possibly bypass intended sandbox restrictions via a large number, which triggers a stack-based buffer overflow. NOTE: this issue exists because of a CVE-2015-8080 regression.
Severity: MEDIUM (CVSS v3 base score: 7.7)
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/antirez/redis
Files changed:
deps/lua/src/lua_struct.c
Commit message: [FIX] revisit CVE-2015-8080 vulnerability


Vulnerable code:
static int getnum (const char **fmt, int df) {
    case 'c': return getnum(fmt, 1);
      int sz = getnum(fmt, sizeof(int));
      int a = getnum(fmt, MAXALIGN);

Fixed code:
static int getnum (lua_State *L, const char **fmt, int df) {
      if (a > (INT_MAX / 10) || a * 10 > (INT_MAX - (**fmt - '0')))
        luaL_error(L, "integral size overflow");
    case 'c': return getnum(L, fmt, 1);
      int sz = getnum(L, fmt, sizeof(int));
      int a = getnum(L, fmt, MAXALIGN);
CVE-2019-18466 (Unknown, published 2019-10-28T13:15Z)
Description: value: An issue was discovered in Podman in libpod before 1.6.0. It resolves a symlink in the host context during a copy operation from the container to the host, because an undesired glob operation occurs. An attacker could create a container image containing particular symlinks that, when copied by a victim user to the host filesystem, may overwrite existing files with others from the host.
Severity: MEDIUM (CVSS v3 base score: 5.5)
Weakness: CWE-59 \u2014 Improper Link Resolution Before File Access ('Link Following')
The product attempts to access a file based on the filename, but it does not properly prevent that filename from identifying a link or shortcut that resolves to an unintended resource.
Repository: https://github.com/containers/libpod
Files changed:
Commit message: Merge pull request #3942 from jwhonce/issue/3829

Stop glob'ing on podman cp

Vulnerable code:

Fixed code:
CVE-2018-3728 (JavaScript, published 2018-03-30T19:29Z)
Description: value: hoek node module before 4.2.0 and 5.0.x before 5.0.3 suffers from a Modification of Assumed-Immutable Data (MAID) vulnerability via 'merge' and 'applyToDefaults' functions, which allows a malicious user to modify the prototype of "Object" via __proto__, causing the addition or modification of an existing property that will exist on all objects.
Severity: MEDIUM (CVSS v3 base score: 8.8)
Weakness: CWE-471 \u2014 Modification of Assumed-Immutable Data (MAID)
The product does not properly protect an assumed-immutable element from being modified by an attacker.
Repository: https://github.com/hapijs/hoek
Files changed:
lib/index.js
test/index.js
Commit message: skip assignment to __proto__


Vulnerable code:

Fixed code:
        if (key === '__proto__') {
            continue;
        }


    it('skips __proto__', () => {

        const a = '{ "ok": "value", "__proto__": { "test": "value" } }';

        const b = Hoek.merge({}, JSON.parse(a));
        expect(b).to.equal({ ok: 'value' });
        expect(b.test).to.equal(undefined);
    });
CVE-2013-0211 (C, published 2013-09-30T22:55Z)
Description: value: Integer signedness error in the archive_write_zip_data function in archive_write_set_format_zip.c in libarchive 3.1.2 and earlier, when running on 64-bit machines, allows context-dependent attackers to cause a denial of service (crash) via unspecified vectors, which triggers an improper conversion between unsigned and signed types, leading to a buffer overflow.
Severity: MEDIUM (CVSS v3 base score: )
Weakness: CWE-189 \u2014 Numeric Errors
Weaknesses in this category are related to improper calculation or conversion of numbers.
Repository: https://github.com/libarchive/libarchive
Files changed:
libarchive/archive_write.c
Commit message: Limit write requests to at most INT_MAX.
This prevents a certain common programming error (passing -1 to write)
from leading to other problems deeper in the library.


Vulnerable code:

Fixed code:
	const size_t max_write = INT_MAX;

	/* In particular, this catches attempts to pass negative values. */
	if (s > max_write)
		s = max_write;