starsofchance/CVEfixes_v1.0.8 huggingface dataset:
CVE-2014-125049 (published 2023-01-06T13:15Z)

** UNSUPPORTED WHEN ASSIGNED ** A vulnerability, which was classified as critical, was found in typcn Blogile. Affected is the function getNav of the file server.js. The manipulation of the argument query leads to sql injection. The name of the patch is cfec31043b562ffefe29fe01af6d3c5ed1bf8f7d. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-217560. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

CVSS v3 base score: 9.8, CRITICAL (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)

Weakness information:
cwe_id: CWE-89
cwe_name: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
description: 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.
extended_description: 
            
            
         
         

Fix information:
repo_url: https://github.com/typcn/Blogile
commit_details: repo_url: https://github.com/typcn/Blogile
author: typcn
author_date: 2014-12-03 09:36:57+08:00
msg: Fix sql injection
repository: repo_url: https://github.com/typcn/Blogile
repo_name: typcn/Blogile
description: A Node.js Blog System (Pending delete, Will be rewrite)
repo_language: JavaScript
owner: typcn
file_changes: filename: package.json
change_type: ModificationType.MODIFY
diff: @@ -1,6 +1,6 @@
 {
   "name": "blogile",
-  "version": "0.0.4",
+  "version": "0.0.5",
   "description": "A simple lightweight blog system.",
   "main": "server.js",
   "repository": "git://github.com/typcn/Blogile.git",

programming_language: JavaScript
filename: server.js
change_type: ModificationType.MODIFY
diff: @@ -634,7 +634,7 @@ function getNav(currpage,subdir){
 }
 
 function searchkey(query,res){
-  connection.query('select * from bi_posts where concat(title,content) like "%'+ query +'%"', function(err, rows) {
+  connection.query('select * from bi_posts where concat(title,content) like "%'+ connection.escape(query) +'%"', function(err, rows) {
     if(err){ log(err,3);}
     if(rows[0] === undefined){
       res.contentType('application/json');

programming_language: JavaScript
CVE-2022-0666 (published 2022-02-18T15:15Z)

CRLF Injection leads to Stack Trace Exposure due to lack of filtering at https://demo.microweber.org/ in Packagist microweber/microweber prior to 1.2.11.

Severity: MEDIUM
CVSS v2 base score: 5.0 (AV:N/AC:L/Au:N/C:P/I:N/A:N)
CVSS v3 base score: 7.5, HIGH (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N)

Weakness information:
cwe_id: CWE-93
cwe_name: Improper Neutralization of CRLF Sequences ('CRLF Injection')
description: The product uses CRLF (carriage return line feeds) as a special element, e.g. to separate lines or records, but it does not neutralize or incorrectly neutralizes CRLF sequences from inputs.
extended_description: 
            
            
         
         

Fix information:
repo_url: https://github.com/microweber/microweber
commit_details: repo_url: https://github.com/microweber/microweber
author: Bozhidar Slaveykov
author_date: 2022-02-17 16:49:46+02:00
msg: Update UrlManager.php
repository: repo_url: https://github.com/microweber/microweber
repo_name: microweber/microweber
description: Drag and Drop Website Builder and CMS with E-commerce
repo_language: HTML
owner: microweber
file_changes: filename: UrlManager.php
change_type: ModificationType.MODIFY
diff: @@ -111,9 +111,8 @@ class UrlManager
             }
         }
 
-        if (!filter_var($redirectUrl, FILTER_VALIDATE_URL)) {
-            $redirectUrl = site_url();
-        }
+        $redirectUrl = str_replace("\r", "", $redirectUrl);
+        $redirectUrl = str_replace("\n", "", $redirectUrl);
 
         if (headers_sent()) {
             echo '<meta http-equiv="refresh" content="0;url=' . $redirectUrl . '">';

programming_language: PHP
CVE-2017-16357 (published 2017-11-01T17:29Z)

In radare 2.0.1, a memory corruption vulnerability exists in store_versioninfo_gnu_verdef() and store_versioninfo_gnu_verneed() in libr/bin/format/elf/elf.c, as demonstrated by an invalid free. This error is due to improper sh_size validation when allocating memory.

Severity: MEDIUM
CVSS v2 base score: 6.8 (AV:N/AC:M/Au:N/C:P/I:P/A:P)
CVSS v3 base score: 7.8, HIGH (CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H)

Weakness information:
cwe_id: CWE-119
cwe_name: Improper Restriction of Operations within the Bounds of a Memory Buffer
description: 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.
extended_description: 
            Certain languages allow direct addressing of memory locations and do not automatically ensure that these locations are valid for the memory buffer that is being referenced. This can cause read or write operations to be performed on memory locations that may be associated with other variables, data structures, or internal program data.
         
         

Fix information:
repo_url: https://github.com/radare/radare2
commit_details: repo_url: https://github.com/radare/radare2
author: Khairul Kasmiran
author_date: 2017-10-28 11:56:30+08:00
msg: Fixed crash in elf.c with 32bit r2 when shdr->sh_size > max size_t
repository: repo_url: https://github.com/radare/radare2
repo_name: radareorg/radare2
description: UNIX-like reverse engineering framework and command-line toolset
repo_language: C
owner: radare
file_changes: filename: elf.c
change_type: ModificationType.MODIFY
diff: @@ -705,7 +705,7 @@ static Sdb *store_versioninfo_gnu_verdef(ELFOBJ *bin, Elf_(Shdr) *shdr, int sz)
 		return false;
 	}
 	link_shdr = &bin->shdr[shdr->sh_link];
-	if (shdr->sh_size < 1) {
+	if (shdr->sh_size < 1 || shdr->sh_size > SIZE_MAX) {
 		return false;
 	}
 	Elf_(Verdef) *defs = calloc (shdr->sh_size, sizeof (char));
@@ -837,7 +837,7 @@ static Sdb *store_versioninfo_gnu_verneed(ELFOBJ *bin, Elf_(Shdr) *shdr, int sz)
 	if (shdr->sh_link > bin->ehdr.e_shnum) {
 		return NULL;
 	}
-	if (shdr->sh_size < 1) {
+	if (shdr->sh_size < 1 || shdr->sh_size > SIZE_MAX) {
 		return NULL;
 	}
 	sdb = sdb_new0 ();

programming_language: C
CVE-2016-7425 (published 2016-10-16T21:59Z)

The arcmsr_iop_message_xfer function in drivers/scsi/arcmsr/arcmsr_hba.c in the Linux kernel through 4.8.2 does not restrict a certain length field, which allows local users to gain privileges or cause a denial of service (heap-based buffer overflow) via an ARCMSR_MESSAGE_WRITE_WQBUFFER control code.

Severity: HIGH
CVSS v2 base score: 7.2 (AV:L/AC:L/Au:N/C:C/I:C/A:C)
CVSS v3 base score: 7.8, HIGH (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)

Weakness information:
cwe_id: CWE-119
cwe_name: Improper Restriction of Operations within the Bounds of a Memory Buffer
description: 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.
extended_description: 
            Certain languages allow direct addressing of memory locations and do not automatically ensure that these locations are valid for the memory buffer that is being referenced. This can cause read or write operations to be performed on memory locations that may be associated with other variables, data structures, or internal program data.
         
         

Fix information:
repo_url: https://github.com/torvalds/linux
commit_details: repo_url: https://github.com/torvalds/linux
author: Dan Carpenter
author_date: 2016-09-15 16:44:56+03:00
msg: scsi: arcmsr: Buffer overflow in arcmsr_iop_message_xfer()

We need to put an upper bound on "user_len" so the memcpy() doesn't
overflow.

Cc: <stable@vger.kernel.org>
Reported-by: Marco Grassi <marco.gra@gmail.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Tomas Henzl <thenzl@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
repository: repo_url: https://github.com/torvalds/linux
repo_name: torvalds/linux
description: Linux kernel source tree
repo_language: C
owner: torvalds
file_changes: filename: arcmsr_hba.c
change_type: ModificationType.MODIFY
diff: @@ -2388,7 +2388,8 @@ static int arcmsr_iop_message_xfer(struct AdapterControlBlock *acb,
 	}
 	case ARCMSR_MESSAGE_WRITE_WQBUFFER: {
 		unsigned char *ver_addr;
-		int32_t user_len, cnt2end;
+		uint32_t user_len;
+		int32_t cnt2end;
 		uint8_t *pQbuffer, *ptmpuserbuffer;
 		ver_addr = kmalloc(ARCMSR_API_DATA_BUFLEN, GFP_ATOMIC);
 		if (!ver_addr) {
@@ -2397,6 +2398,11 @@ static int arcmsr_iop_message_xfer(struct AdapterControlBlock *acb,
 		}
 		ptmpuserbuffer = ver_addr;
 		user_len = pcmdmessagefld->cmdmessage.Length;
+		if (user_len > ARCMSR_API_DATA_BUFLEN) {
+			retvalue = ARCMSR_MESSAGE_FAIL;
+			kfree(ver_addr);
+			goto message_out;
+		}
 		memcpy(ptmpuserbuffer,
 			pcmdmessagefld->messagedatabuffer, user_len);
 		spin_lock_irqsave(&acb->wqbuffer_lock, flags);

programming_language: C
CVE-2024-31583 (published 2024-04-17T19:15Z)

Pytorch before version v2.2.0 was discovered to contain a use-after-free vulnerability in torch/csrc/jit/mobile/interpreter.cpp.


Weakness information:
cwe_id: NVD-CWE-noinfo
cwe_name: Insufficient Information
description: There is insufficient information about the issue to classify it; details are unkown or unspecified.
extended_description: Insufficient Information

Fix information:
repo_url: https://github.com/pytorch/pytorch
commit_details: repo_url: https://github.com/pytorch/pytorch
author: Octavian Guzu
author_date: 2023-09-29 22:32:34+00:00
msg: [fuzzing result][fuzz_torch_jit_lite_interpreter] read-heap-use-after-free (size 8) in std::_Function_base::_M_empty() (#110289)

Summary: This diff fixes a heap UAF found by fuzzing in torch/csrc/jit/mobile/interpreter.cpp

Test Plan:
CI and
```
arc lionhead crash reproduce 1009060456885023
```
doesn't crash anymore.

Reviewed By: malfet

Differential Revision: D49538326

Pull Request resolved: https://github.com/pytorch/pytorch/pull/110289
Approved by: https://github.com/malfet
repository: repo_url: https://github.com/pytorch/pytorch
repo_name: pytorch/pytorch
description: Tensors and Dynamic neural networks in Python with strong GPU acceleration
repo_language: Python
owner: pytorch
file_changes: filename: interpreter.cpp
change_type: ModificationType.MODIFY
diff: @@ -128,7 +128,10 @@ bool InterpreterState::run(Stack& stack) {
               mobile_debug_info->setOpIdx(pc);
             }
           }
-
+          if (inst.X < 0 ||
+              static_cast<size_t>(inst.X) >= code.operators_.size()) {
+            throw JITException("Invalid OP Instruction");
+          }
           RECORD_EDGE_SCOPE_WITH_DEBUG_HANDLE_AND_INPUTS(
               code.op_names_[inst.X].name, debug_handle, stack);
           code.operators_[inst.X](stack);

programming_language: C++
CVE-2022-2289 (published 2022-07-03T15:15Z)

Use After Free in GitHub repository vim/vim prior to 9.0.

Severity: MEDIUM
CVSS v2 base score: 6.8 (AV:N/AC:M/Au:N/C:P/I:P/A:P)
CVSS v3 base score: 7.8, HIGH (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H)

Weakness information:
cwe_id: CWE-416
cwe_name: Use After Free
description: 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.
extended_description: 
             
             
             
			 
             
             
         
         

Fix information:
repo_url: https://github.com/vim/vim
commit_details: repo_url: https://github.com/vim/vim
author: Bram Moolenaar
author_date: 2022-07-02 15:10:00+01:00
msg: patch 9.0.0026: accessing freed memory with diff put

Problem:    Accessing freed memory with diff put.
Solution:   Bail out when diff pointer is no longer valid.
repository: repo_url: https://github.com/vim/vim
repo_name: vim/vim
description: The official Vim repository
repo_language: Vim Script
owner: vim
file_changes: filename: diff.c
change_type: ModificationType.MODIFY
diff: @@ -2642,6 +2642,20 @@ nv_diffgetput(int put, long count)
     ex_diffgetput(&ea);
 }
 
+/*
+ * Return TRUE if "diff" appears in the list of diff blocks of the current tab.
+ */
+    static int
+valid_diff(diff_T *diff)
+{
+    diff_T	*dp;
+
+    for (dp = curtab->tp_first_diff; dp != NULL; dp = dp->df_next)
+	if (dp == diff)
+	    return TRUE;
+    return FALSE;
+}
+
 /*
  * ":diffget"
  * ":diffput"
@@ -2899,9 +2913,9 @@ ex_diffgetput(exarg_T *eap)
 		}
 	    }
 
-	    // Adjust marks.  This will change the following entries!
 	    if (added != 0)
 	    {
+		// Adjust marks.  This will change the following entries!
 		mark_adjust(lnum, lnum + count - 1, (long)MAXLNUM, (long)added);
 		if (curwin->w_cursor.lnum >= lnum)
 		{
@@ -2923,7 +2937,13 @@ ex_diffgetput(exarg_T *eap)
 #endif
 		vim_free(dfree);
 	    }
-	    else
+
+	    // mark_adjust() may have made "dp" invalid.  We don't know where
+	    // to continue then, bail out.
+	    if (added != 0 && !valid_diff(dp))
+		break;
+
+	    if (dfree == NULL)
 		// mark_adjust() may have changed the count in a wrong way
 		dp->df_count[idx_to] = new_count;
 

programming_language: C
filename: version.c
change_type: ModificationType.MODIFY
diff: @@ -735,6 +735,8 @@ static char *(features[]) =
 
 static int included_patches[] =
 {   /* Add new patch number below this line */
+/**/
+    26,
 /**/
     25,
 /**/

programming_language: Ruby
CVE-2021-31661 (published 2021-06-18T22:15Z)

RIOT-OS 2021.01 before commit 609c9ada34da5546cffb632a98b7ba157c112658 contains a buffer overflow that could allow attackers to obtain sensitive information.

Severity: MEDIUM
CVSS v2 base score: 5.0 (AV:N/AC:L/Au:N/C:P/I:N/A:N)
CVSS v3 base score: 7.5, HIGH (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N)

Weakness information:
cwe_id: CWE-120
cwe_name: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
description: 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.
extended_description: A buffer overflow condition exists when a product attempts to put more data in a buffer than it can hold, or when it attempts to put data in a memory area outside of the boundaries of a buffer. The simplest type of error, and the most common cause of buffer overflows, is the "classic" case in which the product copies the buffer without restricting how much is copied. Other variants exist, but the existence of a classic overflow strongly suggests that the programmer is not considering even the most basic of security protections.
         

Fix information:
repo_url: https://github.com/RIOT-OS/RIOT
commit_details: repo_url: https://github.com/RIOT-OS/RIOT
author: Leandro Lanzieri
author_date: 2021-02-10 08:50:10+01:00
msg: Merge pull request #15945 from nmeum/pr/clif_get_attr_bounds

clif: After incrementing pos, make sure it is still in bounds
repository: repo_url: https://github.com/RIOT-OS/RIOT
repo_name: RIOT-OS/RIOT
description: RIOT -  The friendly OS for IoT
repo_language: C
owner: RIOT-OS
CVE-2022-21646 (published 2022-01-11T22:15Z)

SpiceDB is a database system for managing security-critical application permissions. Any user making use of a wildcard relationship under the right hand branch of an `exclusion` or within an `intersection` operation will see `Lookup`/`LookupResources` return a resource as "accessible" if it is *not* accessible by virtue of the inclusion of the wildcard in the intersection or the right side of the exclusion. In `v1.3.0`, the wildcard is ignored entirely in lookup\'s dispatch, resulting in the `banned` wildcard being ignored in the exclusion. Version 1.4.0 contains a patch for this issue. As a workaround, don\'t make use of wildcards on the right side of intersections or within exclusions.

Severity: MEDIUM
CVSS v2 base score: 5.5 (AV:N/AC:L/Au:S/C:P/I:P/A:N)
CVSS v3 base score: 8.1, HIGH (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N)

Weakness information:
cwe_id: NVD-CWE-Other
cwe_name: Other
description: 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.
extended_description: Insufficient Information

Fix information:
repo_url: https://github.com/authzed/spicedb
commit_details: repo_url: https://github.com/authzed/spicedb
author: Joseph Schorr
author_date: 2022-01-11 14:39:23-05:00
msg: Merge pull request from GHSA-7p8f-8hjm-wm92

Fix handling of wildcards in lookup dispatch
repository: repo_url: https://github.com/authzed/spicedb
repo_name: authzed/spicedb
description: Open Source, Google Zanzibar-inspired permissions database to enable fine-grained authorization for customer applications
repo_language: Go
owner: authzed
CVE-2022-1733 (published 2022-05-17T17:15Z)

Heap-based Buffer Overflow in GitHub repository vim/vim prior to 8.2.4968.

Severity: MEDIUM
CVSS v2 base score: 4.6 (AV:L/AC:L/Au:N/C:P/I:P/A:P)
CVSS v3 base score: 7.8, HIGH (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)

Weakness information:
cwe_id: CWE-122
cwe_name: Heap-based Buffer Overflow
description: A heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory, generally meaning that the buffer was allocated using a routine such as malloc().
extended_description: 
            
            
         
         

Fix information:
repo_url: https://github.com/vim/vim
commit_details: repo_url: https://github.com/vim/vim
author: Bram Moolenaar
author_date: 2022-05-16 18:06:15+01:00
msg: patch 8.2.4968: reading past end of the line when C-indenting

Problem:    Reading past end of the line when C-indenting.
Solution:   Check for NUL.
repository: repo_url: https://github.com/vim/vim
repo_name: vim/vim
description: The official Vim repository
repo_language: Vim Script
owner: vim
file_changes: filename: cindent.c
change_type: ModificationType.MODIFY
diff: @@ -89,7 +89,7 @@ skip_string(char_u *p)
 		while (vim_isdigit(p[i - 1]))   // '\000'
 		    ++i;
 	    }
-	    if (p[i] == '\'')		    // check for trailing '
+	    if (p[i - 1] != NUL && p[i] == '\'')    // check for trailing '
 	    {
 		p += i;
 		continue;

programming_language: C
filename: test_cindent.vim
change_type: ModificationType.MODIFY
diff: @@ -5319,6 +5319,13 @@ func Test_cindent_change_multline()
   close!
 endfunc
 
+" This was reading past the end of the line
+func Test_cindent_check_funcdecl()
+  new
+  sil norm o0('\0=L
+  bwipe!
+endfunc
+
 func Test_cindent_scopedecls()
   new
   setl cindent ts=4 sw=4

programming_language: C
filename: version.c
change_type: ModificationType.MODIFY
diff: @@ -746,6 +746,8 @@ static char *(features[]) =
 
 static int included_patches[] =
 {   /* Add new patch number below this line */
+/**/
+    4968,
 /**/
     4967,
 /**/

programming_language: Ruby
CVE-2014-3183 (published 2014-09-28T10:55Z)

Heap-based buffer overflow in the logi_dj_ll_raw_request function in drivers/hid/hid-logitech-dj.c in the Linux kernel before 3.16.2 allows physically proximate attackers to cause a denial of service (system crash) or possibly execute arbitrary code via a crafted device that specifies a large report size for an LED report.

Severity: MEDIUM
CVSS v2 base score: 6.9 (AV:L/AC:M/Au:N/C:C/I:C/A:C)

Weakness information:
cwe_id: CWE-119
cwe_name: Improper Restriction of Operations within the Bounds of a Memory Buffer
description: 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.
extended_description: 
            Certain languages allow direct addressing of memory locations and do not automatically ensure that these locations are valid for the memory buffer that is being referenced. This can cause read or write operations to be performed on memory locations that may be associated with other variables, data structures, or internal program data.
         
         

Fix information:
repo_url: https://github.com/torvalds/linux
commit_details: repo_url: https://github.com/torvalds/linux
author: Jiri Kosina
author_date: 2014-08-21 09:56:47-05:00
msg: HID: logitech: fix bounds checking on LED report size

The check on report size for REPORT_TYPE_LEDS in logi_dj_ll_raw_request()
is wrong; the current check doesn't make any sense -- the report allocated
by HID core in hid_hw_raw_request() can be much larger than
DJREPORT_SHORT_LENGTH, and currently logi_dj_ll_raw_request() doesn't
handle this properly at all.

Fix the check by actually trimming down the report size properly if it is
too large.

Cc: stable@vger.kernel.org
Reported-by: Ben Hawkes <hawkes@google.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
repository: repo_url: https://github.com/torvalds/linux
repo_name: torvalds/linux
description: Linux kernel source tree
repo_language: C
owner: torvalds
file_changes: filename: hid-logitech-dj.c
change_type: ModificationType.MODIFY
diff: @@ -557,7 +557,7 @@ static int logi_dj_ll_raw_request(struct hid_device *hid,
 	if (!out_buf)
 		return -ENOMEM;
 
-	if (count < DJREPORT_SHORT_LENGTH - 2)
+	if (count > DJREPORT_SHORT_LENGTH - 2)
 		count = DJREPORT_SHORT_LENGTH - 2;
 
 	out_buf[0] = REPORT_ID_DJ_SHORT;

programming_language: C