hitoshura25/cvefixes huggingface dataset:
CVE-2020-15888 (C, published 2020-07-21T22:15Z)
Description: value: Lua through 5.4.0 mishandles the interaction between stack resizes and garbage collection, leading to a heap-based buffer overflow, heap-based buffer over-read, or use-after-free.
Severity: MEDIUM (CVSS v3 base score: 8.8)
Weakness: CWE-416 \u2014 Use After Free
The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.
Repository: https://github.com/lua/lua
Files changed:
ldo.c
Commit message: Keep minimum size when shrinking a stack

When shrinking a stack (during GC), do not make it smaller than the
initial stack size.


Vulnerable code:
  int goodsize = inuse + (inuse / 8) + 2*EXTRA_STACK;
  if (inuse <= (LUAI_MAXSTACK - EXTRA_STACK) &&
      goodsize < L->stacksize)

Fixed code:
  int goodsize = inuse + BASIC_STACK_SIZE;
  if (inuse <= (LUAI_MAXSTACK - EXTRA_STACK) && goodsize < L->stacksize)
CVE-2020-15888 (C, published 2020-07-21T22:15Z)
Description: value: Lua through 5.4.0 mishandles the interaction between stack resizes and garbage collection, leading to a heap-based buffer overflow, heap-based buffer over-read, or use-after-free.
Severity: MEDIUM (CVSS v3 base score: 8.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/lua/lua
Files changed:
ldo.c
Commit message: Keep minimum size when shrinking a stack

When shrinking a stack (during GC), do not make it smaller than the
initial stack size.


Vulnerable code:
  int goodsize = inuse + (inuse / 8) + 2*EXTRA_STACK;
  if (inuse <= (LUAI_MAXSTACK - EXTRA_STACK) &&
      goodsize < L->stacksize)

Fixed code:
  int goodsize = inuse + BASIC_STACK_SIZE;
  if (inuse <= (LUAI_MAXSTACK - EXTRA_STACK) && goodsize < L->stacksize)
CVE-2020-15888 (C, published 2020-07-21T22:15Z)
Description: value: Lua through 5.4.0 mishandles the interaction between stack resizes and garbage collection, leading to a heap-based buffer overflow, heap-based buffer over-read, or use-after-free.
Severity: MEDIUM (CVSS v3 base score: 8.8)
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/lua/lua
Files changed:
ldo.c
ldo.h
ltm.c
lvm.c
Commit message: Fixed bugs of stack reallocation x GC

Macro 'checkstackGC' was doing a GC step after resizing the stack;
the GC could shrink the stack and undo the resize. Moreover, macro
'checkstackp' also does a GC step, which could remove the preallocated
CallInfo when calling a function. (Its name has been changed to
'checkstackGCp' to emphasize that it calls the GC.)


Vulnerable code:
      CallInfo *ci = next_ci(L);
      checkstackp(L, LUA_MINSTACK, func);  /* ensure minimum stack size */
      L->ci = ci;
      CallInfo *ci = next_ci(L);
      checkstackp(L, fsize, func);
      checkstackp(L, 1, func);  /* space for metamethod */
#define checkstackp(L,n,p)  \
	luaD_checkstackaux(L, (fsize), (void)0, luaC_checkGC(L))
  checkstackGC(L, p->maxstacksize + 1);
    checkstackp(L, nextra, where);  /* ensure stack space */
          checkstackp(L, 1, ra);

Fixed code:
      CallInfo *ci;
      checkstackGCp(L, LUA_MINSTACK, func);  /* ensure minimum stack size */
      L->ci = ci = next_ci(L);
      CallInfo *ci;
      checkstackGCp(L, fsize, func);
      L->ci = ci = next_ci(L);
      checkstackGCp(L, 1, func);  /* space for metamethod */
** It also allows the running of one GC step when the stack is
** reallocated.
#define checkstackGCp(L,n,p)  \
	luaD_checkstackaux(L, (fsize), luaC_checkGC(L), (void)0)
  luaD_checkstack(L, p->maxstacksize + 1);
    checkstackGCp(L, nextra, where);  /* ensure stack space */
          checkstackGCp(L, 1, ra);
CVE-2020-15888 (C, published 2020-07-21T22:15Z)
Description: value: Lua through 5.4.0 mishandles the interaction between stack resizes and garbage collection, leading to a heap-based buffer overflow, heap-based buffer over-read, or use-after-free.
Severity: MEDIUM (CVSS v3 base score: 8.8)
Weakness: CWE-416 \u2014 Use After Free
The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.
Repository: https://github.com/lua/lua
Files changed:
ldo.c
ldo.h
ltm.c
lvm.c
Commit message: Fixed bugs of stack reallocation x GC

Macro 'checkstackGC' was doing a GC step after resizing the stack;
the GC could shrink the stack and undo the resize. Moreover, macro
'checkstackp' also does a GC step, which could remove the preallocated
CallInfo when calling a function. (Its name has been changed to
'checkstackGCp' to emphasize that it calls the GC.)


Vulnerable code:
      CallInfo *ci = next_ci(L);
      checkstackp(L, LUA_MINSTACK, func);  /* ensure minimum stack size */
      L->ci = ci;
      CallInfo *ci = next_ci(L);
      checkstackp(L, fsize, func);
      checkstackp(L, 1, func);  /* space for metamethod */
#define checkstackp(L,n,p)  \
	luaD_checkstackaux(L, (fsize), (void)0, luaC_checkGC(L))
  checkstackGC(L, p->maxstacksize + 1);
    checkstackp(L, nextra, where);  /* ensure stack space */
          checkstackp(L, 1, ra);

Fixed code:
      CallInfo *ci;
      checkstackGCp(L, LUA_MINSTACK, func);  /* ensure minimum stack size */
      L->ci = ci = next_ci(L);
      CallInfo *ci;
      checkstackGCp(L, fsize, func);
      L->ci = ci = next_ci(L);
      checkstackGCp(L, 1, func);  /* space for metamethod */
** It also allows the running of one GC step when the stack is
** reallocated.
#define checkstackGCp(L,n,p)  \
	luaD_checkstackaux(L, (fsize), luaC_checkGC(L), (void)0)
  luaD_checkstack(L, p->maxstacksize + 1);
    checkstackGCp(L, nextra, where);  /* ensure stack space */
          checkstackGCp(L, 1, ra);
CVE-2020-15888 (C, published 2020-07-21T22:15Z)
Description: value: Lua through 5.4.0 mishandles the interaction between stack resizes and garbage collection, leading to a heap-based buffer overflow, heap-based buffer over-read, or use-after-free.
Severity: MEDIUM (CVSS v3 base score: 8.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/lua/lua
Files changed:
ldo.c
ldo.h
ltm.c
lvm.c
Commit message: Fixed bugs of stack reallocation x GC

Macro 'checkstackGC' was doing a GC step after resizing the stack;
the GC could shrink the stack and undo the resize. Moreover, macro
'checkstackp' also does a GC step, which could remove the preallocated
CallInfo when calling a function. (Its name has been changed to
'checkstackGCp' to emphasize that it calls the GC.)


Vulnerable code:
      CallInfo *ci = next_ci(L);
      checkstackp(L, LUA_MINSTACK, func);  /* ensure minimum stack size */
      L->ci = ci;
      CallInfo *ci = next_ci(L);
      checkstackp(L, fsize, func);
      checkstackp(L, 1, func);  /* space for metamethod */
#define checkstackp(L,n,p)  \
	luaD_checkstackaux(L, (fsize), (void)0, luaC_checkGC(L))
  checkstackGC(L, p->maxstacksize + 1);
    checkstackp(L, nextra, where);  /* ensure stack space */
          checkstackp(L, 1, ra);

Fixed code:
      CallInfo *ci;
      checkstackGCp(L, LUA_MINSTACK, func);  /* ensure minimum stack size */
      L->ci = ci = next_ci(L);
      CallInfo *ci;
      checkstackGCp(L, fsize, func);
      L->ci = ci = next_ci(L);
      checkstackGCp(L, 1, func);  /* space for metamethod */
** It also allows the running of one GC step when the stack is
** reallocated.
#define checkstackGCp(L,n,p)  \
	luaD_checkstackaux(L, (fsize), luaC_checkGC(L), (void)0)
  luaD_checkstack(L, p->maxstacksize + 1);
    checkstackGCp(L, nextra, where);  /* ensure stack space */
          checkstackGCp(L, 1, ra);
CVE-2020-15889 (C, published 2020-07-21T22:15Z)
Description: value: Lua 5.4.0 has a getobjname heap-based buffer over-read because youngcollection in lgc.c uses markold for an insufficient number of list members.
Severity: HIGH (CVSS v3 base score: 9.8)
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/lua/lua
Files changed:
lgc.c
Commit message: Fixed bug of old finalized objects in the GC

When an object aged OLD1 is finalized, it is moved from the list
'finobj' to the *beginning* of the list 'allgc'. So, this part of the
list (and not only the survival list) must be visited by 'markold'.


Vulnerable code:
** Does a young collection. First, mark 'OLD1' objects.  (Only survival
** and "recent old" lists can contain 'OLD1' objects. New lists cannot
** contain 'OLD1' objects, at most 'OLD0' objects that were already
** visited when marked old.) Then does the atomic step. Then,
** sweep all lists and advance pointers. Finally, finish the collection.
  markold(g, g->survival, g->reallyold);

Fixed code:
** Does a young collection. First, mark 'OLD1' objects. Then does the
** atomic step. Then, sweep all lists and advance pointers. Finally,
** finish the collection.
  markold(g, g->allgc, g->reallyold);
CVE-2020-24342 (C, published 2020-08-13T19:15Z)
Description: value: Lua through 5.4.0 allows a stack redzone cross in luaO_pushvfstring because a protection mechanism wrongly calls luaD_callnoyield twice in a row.
Severity: MEDIUM (CVSS v3 base score: 7.8)
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/lua/lua
Files changed:
ldo.c
Commit message: Fixed bug: 'luaD_callnoyield' called twice in a row

In luaD_callnoyield, when there is a possible stack overflow, it
zeros the number of CallInfos to force a check when calling the
function. However, if the "function" is not a function, the code will
raise an error before checking the stack. Then, the error handling calls
luaD_callnoyield again and nCcalls is decremented again, crossing the
stack redzone without raising an error. (This loop can only happens
once, because the error handler must be a function.  But once is enough
to cross the redzone.)


Vulnerable code:
** If there is a stack overflow, freeing all CI structures will
** force the subsequent call to invoke 'luaE_extendCI', which then
** will raise any errors.
  if (getCcalls(L) <= CSTACKERR)  /* possible stack overflow? */
    luaE_freeCI(L);

Fixed code:
  if (getCcalls(L) <= CSTACKERR) {  /* possible C stack overflow? */
    luaE_exitCcall(L);  /* to compensate decrement in next call */
    luaE_enterCcall(L);  /* check properly */
  }
CVE-2020-24369 (C, published 2020-08-17T17:15Z)
Description: value: ldebug.c in Lua 5.4.0 attempts to access debug information via the line hook of a stripped function, leading to a NULL pointer dereference.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-476 \u2014 NULL Pointer Dereference
The product dereferences a pointer that it expects to be valid but is NULL.
Repository: https://github.com/lua/lua
Files changed:
ldebug.c
testes/db.lua
Commit message: Fixed bug: line hooks in stripped functions

Line-hook handling was accessing debug info. without checking whether
it was present.


Vulnerable code:
  return 0;  /* no line changes in the way */
prog = [[-- program to be loaded without debug information

Fixed code:
  if (p->lineinfo == NULL)  /* no debug information? */
    return 0;
  return 0;  /* no line changes between positions */
prog = [[-- program to be loaded without debug information (strip)
do   -- bug in 5.4.0: line hooks in stripped code
  local function foo ()
    local a = 1
    local b = 2
    return b
  end

  local s = load(string.dump(foo, true))
  local line = true
  debug.sethook(function (e, l)
    assert(e == "line")
    line = l
  end, "l")
  assert(s() == 2); debug.sethook(nil)
  assert(line == nil)  -- hook called withoug debug info for 1st instruction
end
CVE-2020-24370 (C, published 2020-08-17T17:15Z)
Description: value: ldebug.c in Lua 5.4.0 allows a negation overflow and segmentation fault in getlocal and setlocal, as demonstrated by getlocal(3,2^31).
Severity: MEDIUM (CVSS v3 base score: 5.3)
Weakness: CWE-191 \u2014 Integer Underflow (Wrap or Wraparound)
The product subtracts one value from another, such that the result is less than the minimum allowable integer value, which produces a value that is not equal to the correct result.
Repository: https://github.com/lua/lua
Files changed:
ldebug.c
Commit message: Fixed bug: Negation overflow in getlocal/setlocal


Vulnerable code:
    if (n <= nextra) {
      *pos = ci->func - nextra + (n - 1);
      return findvararg(ci, -n, pos);

Fixed code:
    if (n >= -nextra) {  /* 'n' is negative */
      *pos = ci->func - nextra - (n + 1);
      return findvararg(ci, n, pos);
CVE-2021-45985 (C, published 2023-04-10T09:15Z)
Description: value: In Lua 5.4.3, an erroneous finalizer called during a tail call leads to a heap-based buffer over-read.
Severity: nan (CVSS v3 base score: 7.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/lua/lua
Files changed:
ldo.c
Commit message: Bug: finalizers can be called with an invalid stack

The call to 'checkstackGC' can run finalizers, which will find an
inconsistent CallInfo, as 'ci' is half updated at the point of call.


Vulnerable code:
      checkstackGC(L, fsize);

Fixed code:
      checkstackGCp(L, fsize - delta, func);
CVE-2022-28805 (C, published 2022-04-08T06:15Z)
Description: value: singlevar in lparser.c in Lua from (including) 5.4.0 up to (excluding) 5.4.4 lacks a certain luaK_exp2anyregup call, leading to a heap-based buffer over-read that might affect a system that compiles untrusted Lua code.
Severity: MEDIUM (CVSS v3 base score: 9.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/lua/lua
Files changed:
lparser.c
testes/attrib.lua
Commit message: Bug: Lua can generate wrong code when _ENV is <const>


Vulnerable code:

Fixed code:
    luaK_exp2anyregup(fs, var);  /* but could be a constant */
do
  -- _ENV constant
  local function foo ()
    local _ENV <const> = 11
    X = "hi"
  end
  local st, msg = pcall(foo)
  assert(not st and string.find(msg, "number"))
end
CVE-2022-33099 (C, published 2022-07-01T12:15Z)
Description: value: An issue in the component luaG_runerror of Lua v5.4.4 and below leads to a heap-buffer overflow when a recursive error occurs.
Severity: MEDIUM (CVSS v3 base score: 7.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/lua/lua
Files changed:
ldebug.c
lvm.c
Commit message: Save stack space while handling errors

Because error handling (luaG_errormsg) uses slots from EXTRA_STACK,
and some errors can recur (e.g., string overflow while creating an
error message in 'luaG_runerror', or a C-stack overflow before calling
the message handler), the code should use stack slots with parsimony.

This commit fixes the bug "Lua-stack overflow when C stack overflows
while handling an error".


Vulnerable code:
  if (isLua(ci))  /* if Lua function, add source:line information */
        if (l_unlikely(l >= (MAX_SIZE/sizeof(char)) - tl))
    L->top -= n-1;  /* popped 'n' strings and pushed one */

Fixed code:
  if (isLua(ci)) {  /* if Lua function, add source:line information */
    setobjs2s(L, L->top - 2, L->top - 1);  /* remove 'msg' from the stack */
    L->top--;
  }
        if (l_unlikely(l >= (MAX_SIZE/sizeof(char)) - tl)) {
          L->top = top - total;  /* pop strings to avoid wasting stack */
        }
    L->top = top - (n - 1);  /* popped 'n' strings and pushed one */
CVE-2023-40586 (Go, published 2023-08-25T21:15Z)
Description: value: OWASP Coraza WAF is a golang modsecurity compatible web application firewall library. Due to the misuse of `log.Fatalf`, the application using coraza crashed after receiving crafted requests from attackers. The application will immediately crash after receiving a malicious request that triggers an error in `mime.ParseMediaType`. This issue was patched in version 3.0.1.

Severity: nan (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/corazawaf/coraza
Files changed:
internal/bodyprocessors/multipart.go
internal/bodyprocessors/multipart_test.go
Commit message: Merge pull request from GHSA-c2pj-v37r-2p6h



Vulnerable code:
	"log"
		log.Fatalf("failed to parse media type: %s", err.Error())

Fixed code:
		return err

func TestInvalidMultipartCT(t *testing.T) {
	payload := strings.TrimSpace(`
-----------------------------9051914041544843365972754266
Content-Disposition: form-data; name="text"

text default
-----------------------------9051914041544843365972754266
`)
	mp := multipartProcessor(t)
	v := corazawaf.NewTransactionVariables()
	if err := mp.ProcessRequest(strings.NewReader(payload), v, plugintypes.BodyProcessorOptions{
		Mime: "multipart/form-data; boundary=---------------------------9051914041544843365972754266; a=1; a=2",
	}); err == nil {
		t.Error("multipart processor should fail for invalid content-type")
	}
}
CVE-2020-7981 (Ruby, published 2020-01-25T20:15Z)
Description: value: sql.rb in Geocoder before 1.6.1 allows Boolean-based SQL injection when within_bounding_box is used in conjunction with untrusted sw_lat, sw_lng, ne_lat, or ne_lng data.
Severity: HIGH (CVSS v3 base score: 9.8)
Weakness: CWE-89 \u2014 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data.
Repository: https://github.com/alexreisner/geocoder
Files changed:
lib/geocoder/sql.rb
Commit message: Sanitize lat/lon for SQL query.


Vulnerable code:
      spans = "#{lat_attr} BETWEEN #{sw_lat} AND #{ne_lat} AND "
        spans + "(#{lon_attr} BETWEEN #{sw_lng} AND 180 OR " +
        "#{lon_attr} BETWEEN -180 AND #{ne_lng})"
        spans + "#{lon_attr} BETWEEN #{sw_lng} AND #{ne_lng}"

Fixed code:
      spans = "#{lat_attr} BETWEEN #{sw_lat.to_f} AND #{ne_lat.to_f} AND "
        spans + "(#{lon_attr} BETWEEN #{sw_lng.to_f} AND 180 OR " +
        "#{lon_attr} BETWEEN -180 AND #{ne_lng.to_f})"
        spans + "#{lon_attr} BETWEEN #{sw_lng.to_f} AND #{ne_lng.to_f}"
CVE-2022-23465 (Swift, published 2022-12-02T23:15Z)
Description: value: SwiftTerm is a Xterm/VT100 Terminal emulator. Prior to commit a94e6b24d24ce9680ad79884992e1dff8e150a31, an attacker could modify the window title via a certain character escape sequence and then insert it back to the command line in the user's terminal, e.g. when the user views a file containing the malicious sequence, which could allow the attacker to execute arbitrary commands. Version a94e6b24d24ce9680ad79884992e1dff8e150a31 contains a patch for this issue. There are no known workarounds available.
Severity: nan (CVSS v3 base score: 7.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/migueldeicaza/SwiftTerm
Files changed:
Sources/SwiftTerm/Terminal.swift
Commit message: Fix two possible attack vectors, where an attacker can store
information into the termianl and then get to replay it.

Two of those instances are setting the terminal title, and icon title,
and then requesting the values back (see CVE-2003-0063[2] and
https://marc.info/?l=bugtraq&m=104612710031920&w=2 for details).

And another case is sending an invalid DECRQSS sequence, which the
handler would respond back with the results, see here for how this is
used: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510030 CVE-2008-2383[3]

These bugs were found and disclosed by David Leadbeater <dgl@dgl.cx>
(@dgl at Github.com)


Vulnerable code:
                result = newData ?? ""
            let it = iconTitle.replacingOccurrences(of: "\\", with: "")
            sendResponse (cc.OSC, "L\(it)", cc.ST)
            let tt = terminalTitle.replacingOccurrences(of: "\\", with: "")
            sendResponse (cc.OSC, "l\(tt)", cc.ST)

Fixed code:
                // Do not report 'newData', because it can be exploited
                // see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510030
                result = ""
            // Do not report the actual title back, as it can be exploited,
            // https://marc.info/?l=bugtraq&m=104612710031920&w=2
            sendResponse (cc.OSC, "L", cc.ST)
            // Do not report the actual content of the title back, as it can be exploited,
            // https://marc.info/?l=bugtraq&m=104612710031920&w=2
            sendResponse (cc.OSC, "l", cc.ST)
CVE-2023-5948 (Unknown, published 2023-11-03T07:15Z)
Description: value: Improper Authorization in GitHub repository teamamaze/amazefileutilities prior to 1.91.
Severity: nan (CVSS v3 base score: 5.5)
Weakness: CWE-285 \u2014 Improper Authorization
The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.
Repository: https://github.com/teamamaze/amazefileutilities
Files changed:
Commit message: Merge pull request #127 from TeamAmaze/bugfix/welcomescreen

Monkeypatch WelcomePermissionScreen to prevent unintentional Intents

Vulnerable code:

Fixed code:
CVE-2022-2365 (JavaScript, published 2022-07-10T22:15Z)
Description: value: Cross-site Scripting (XSS) - Stored in GitHub repository zadam/trilium prior to 0.53.3.
Severity: LOW (CVSS v3 base score: 5.4)
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/zadam/trilium
Files changed:
src/public/app/widgets/dialogs/export.js
Commit message: fix note title escaping in export dialog


Vulnerable code:

        const noteTitle = await treeService.getNoteTitle(noteId);

        this.$noteTitle.html(noteTitle);

Fixed code:
        this.$noteTitle.text(await treeService.getNoteTitle(noteId));