starsofchance/CVEfixes_v1.0.8 huggingface dataset:
CVE-2022-24959 (published 2022-02-11T06:15Z)

An issue was discovered in the Linux kernel before 5.16.5. There is a memory leak in yam_siocdevprivate in drivers/net/hamradio/yam.c.

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

Weakness information:
cwe_id: CWE-401
cwe_name: Missing Release of Memory after Effective Lifetime
description: The product does not sufficiently track and release allocated memory after it has been used, which slowly consumes remaining memory.
extended_description: This is often triggered by improper handling of malformed data or unexpectedly interrupted sessions.  In some languages, developers are responsible for tracking memory allocation and releasing the memory.  If there are no more pointers or references to the memory, then it can no longer be tracked and identified for release.
         

Fix information:
repo_url: https://github.com/torvalds/linux
commit_details: repo_url: https://github.com/torvalds/linux
author: Hangyu Hua
author_date: 2022-01-24 11:29:54+08:00
msg: yam: fix a memory leak in yam_siocdevprivate()

ym needs to be free when ym->cmd != SIOCYAMSMCS.

Fixes: 0781168e23a2 ("yam: fix a missing-check bug")
Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
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: yam.c
change_type: ModificationType.MODIFY
diff: @@ -950,9 +950,7 @@ static int yam_siocdevprivate(struct net_device *dev, struct ifreq *ifr, void __
 		ym = memdup_user(data, sizeof(struct yamdrv_ioctl_mcs));
 		if (IS_ERR(ym))
 			return PTR_ERR(ym);
-		if (ym->cmd != SIOCYAMSMCS)
-			return -EINVAL;
-		if (ym->bitrate > YAM_MAXBITRATE) {
+		if (ym->cmd != SIOCYAMSMCS || ym->bitrate > YAM_MAXBITRATE) {
 			kfree(ym);
 			return -EINVAL;
 		}

programming_language: C
CVE-2021-25916 (published 2021-03-16T16:15Z)

Prototype pollution vulnerability in 'patchmerge' versions 1.0.0 through 1.0.1 allows an attacker to cause a denial of service and may lead to remote code execution.

Severity: HIGH
CVSS v2 base score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)
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-1321
cwe_name: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
description: The product receives input from an upstream component that specifies attributes that are to be initialized or updated in an object, but it does not properly control modifications of attributes of the object prototype.
extended_description: 
				By adding or modifying attributes of an object prototype, it is possible to create attributes that exist on every object, or replace critical attributes with malicious ones. This can be problematic if the product depends on existence or non-existence of certain attributes, or uses pre-defined attributes of object prototype (such as hasOwnProperty, toString or valueOf).
				This weakness is usually exploited by using a special attribute of objects called proto,  constructor or prototype. Such attributes give access to the object prototype. This weakness is often found in code that assigns object attributes based on user input, or merges or clones objects recursively.
			
			

Fix information:
repo_url: https://github.com/pjshumphreys/patchmerge
commit_details: repo_url: https://github.com/pjshumphreys/patchmerge
author: Paul Humphreys
author_date: 2021-03-10 16:48:02+00:00
msg: don't inadvertantly modify Object.prototype
repository: repo_url: https://github.com/pjshumphreys/patchmerge
repo_name: pjshumphreys/patchmerge
description: Merges JavaScript object literals similarly to RFC 7396, but with extra support for arrays of objects
repo_language: JavaScript
owner: pjshumphreys
file_changes: filename: index.js
change_type: ModificationType.MODIFY
diff: @@ -102,6 +102,17 @@ const objectMerge = (original, patch, removeMode) => {
     }
     //merge objects
     else {
+      //Don't implicitly mutate Object.prototype but subsitute an empty object
+      if(original[name] === Object.prototype) {
+        delete original[name];
+
+        Object.defineProperty(original, name, {
+          enumerable: true,
+          writable: true,
+          value: {}
+        });
+      }
+
       original[name] = objectMerge(original[name], patch[name], removeMode);
     }
   }

programming_language: Scala
filename: test2.js
change_type: ModificationType.ADD
diff: @@ -0,0 +1,5 @@
+patchMerge = require('./index.js');
+var obj = {}
+console.log("Before : " + obj.isAdmin);
+console.log(patchMerge(obj, JSON.parse('{ "__proto__": { "isAdmin": true }}')));
+console.log("After : " + obj.isAdmin);

programming_language: JavaScript
CVE-2021-23353 (published 2021-03-09T19:15Z)

This affects the package jspdf before 2.3.1. ReDoS is possible via the addImage function.

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

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/MrRio/jsPDF
commit_details: repo_url: https://github.com/MrRio/jsPDF
author: Yeting Li
author_date: 2021-02-11 23:50:17+08:00
msg: fix ReDoS-vulnerable regexp in addImage (#3091)
repository: repo_url: https://github.com/MrRio/jsPDF
repo_name: parallax/jsPDF
description: Client-side JavaScript PDF generation for everyone.
repo_language: JavaScript
owner: MrRio
file_changes: filename: addimage.js
change_type: ModificationType.MODIFY
diff: @@ -630,7 +630,7 @@ import { atob, btoa } from "../libs/AtobBtoa.js";
     var result = null;
 
     if (dataUrlParts.length === 2) {
-      var extractedInfo = /^data:(\w*\/\w*);*(charset=[\w=-]*)*;*$/.exec(
+      var extractedInfo = /^data:(\w*\/\w*);*(charset=(?!charset=)[\w=-]*)*;*$/.exec(
         dataUrlParts[0]
       );
       if (Array.isArray(extractedInfo)) {

programming_language: JavaScript
CVE-2022-48619 (published 2024-01-12T03:15Z)

An issue was discovered in drivers/input/input.c in the Linux kernel before 5.17.10. An attacker can cause a denial of service (panic) because input_set_capability mishandles the situation in which an event code falls outside of a bitmap.

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

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/torvalds/linux
commit_details: repo_url: https://github.com/torvalds/linux
author: Jeff LaBundy
author_date: 2022-03-20 21:55:27-07:00
msg: Input: add bounds checking to input_set_capability()

Update input_set_capability() to prevent kernel panic in case the
event code exceeds the bitmap for the given event type.

Suggested-by: Tomasz Moń <tomasz.mon@camlingroup.com>
Signed-off-by: Jeff LaBundy <jeff@labundy.com>
Reviewed-by: Tomasz Moń <tomasz.mon@camlingroup.com>
Link: https://lore.kernel.org/r/20220320032537.545250-1-jeff@labundy.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.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: input.c
change_type: ModificationType.MODIFY
diff: @@ -47,6 +47,17 @@ static DEFINE_MUTEX(input_mutex);
 
 static const struct input_value input_value_sync = { EV_SYN, SYN_REPORT, 1 };
 
+static const unsigned int input_max_code[EV_CNT] = {
+	[EV_KEY] = KEY_MAX,
+	[EV_REL] = REL_MAX,
+	[EV_ABS] = ABS_MAX,
+	[EV_MSC] = MSC_MAX,
+	[EV_SW] = SW_MAX,
+	[EV_LED] = LED_MAX,
+	[EV_SND] = SND_MAX,
+	[EV_FF] = FF_MAX,
+};
+
 static inline int is_event_supported(unsigned int code,
 				     unsigned long *bm, unsigned int max)
 {
@@ -2110,6 +2121,14 @@ EXPORT_SYMBOL(input_get_timestamp);
  */
 void input_set_capability(struct input_dev *dev, unsigned int type, unsigned int code)
 {
+	if (type < EV_CNT && input_max_code[type] &&
+	    code > input_max_code[type]) {
+		pr_err("%s: invalid code %u for type %u\n", __func__, code,
+		       type);
+		dump_stack();
+		return;
+	}
+
 	switch (type) {
 	case EV_KEY:
 		__set_bit(code, dev->keybit);

programming_language: C
CVE-2012-1122 (published 2012-06-29T19:55Z)

bug_actiongroup.php in MantisBT before 1.2.9 does not properly check the report_bug_threshold permission of the receiving project when moving a bug report, which allows remote authenticated users with the report_bug_threshold and move_bug_threshold privileges for a project to bypass intended access restrictions and move bug reports to a different project.

Severity: LOW
CVSS v2 base score: 3.6 (AV:N/AC:H/Au:S/C:N/I:P/A:P)

Weakness information:
cwe_id: CWE-264
cwe_name: Permissions, Privileges, and Access Controls
description: Weaknesses in this category are related to the management of permissions, privileges, and other security features that are used to perform access control.

Fix information:
repo_url: https://github.com/mantisbt/mantisbt
commit_details: repo_url: https://github.com/mantisbt/mantisbt
author: Damien Regad
author_date: 2012-01-09 14:10:43+01:00
msg: Fix Move bugs from projects with access < report_bug_threshold

The access check in bug_actiongroup.php was not correct. It should
verify the user's report_bug_threshold in the target project, not the
current project.

Fixes #13748
repository: repo_url: https://github.com/mantisbt/mantisbt
repo_name: mantisbt/mantisbt
description: Mantis Bug Tracker (MantisBT)
repo_language: PHP
owner: mantisbt
file_changes: filename: bug_actiongroup.php
change_type: ModificationType.MODIFY
diff: @@ -136,8 +136,8 @@ foreach( $f_bug_arr as $t_bug_id ) {
 
 	case 'MOVE':
 		$f_project_id = gpc_get_int( 'project_id' );
-		if ( access_has_bug_level( config_get( 'move_bug_threshold' ), $t_bug_id ) &&
-		     access_has_project_level( config_get( 'report_bug_threshold' ), $f_project_id ) ) {
+		if( access_has_bug_level( config_get( 'move_bug_threshold' ), $t_bug_id ) &&
+		    access_has_project_level( config_get( 'report_bug_threshold', null, null, $f_project_id ), $f_project_id ) ) {
 			/** @todo we need to issue a helper_call_custom_function( 'issue_update_validate', array( $t_bug_id, $t_bug_data, $f_bugnote_text ) ); */
 			bug_move( $t_bug_id, $f_project_id );
 			helper_call_custom_function( 'issue_update_notify', array( $t_bug_id ) );

programming_language: PHP
CVE-2018-7634 (published 2018-03-01T23:29Z)

An issue was discovered in Enalean Tuleap 9.17. Lack of CSRF attack mitigation while changing an e-mail address makes it possible to abuse the functionality by attackers. By making a CSRF attack, an attacker could make a victim change his registered e-mail address on the application, leading to account takeover.

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

Weakness information:
cwe_id: CWE-352
cwe_name: Cross-Site Request Forgery (CSRF)
description: The web application does not, or can not, sufficiently verify whether a well-formed, valid, consistent request was intentionally provided by the user who submitted the request.
extended_description: When a web server is designed to receive a request from a client without any mechanism for verifying that it was intentionally sent, then it might be possible for an attacker to trick a client into making an unintentional request to the web server which will be treated as an authentic request. This can be done via a URL, image load, XMLHttpRequest, etc. and can result in exposure of data or unintended code execution.
         

Fix information:
repo_url: https://github.com/Enalean/tuleap
commit_details: repo_url: https://github.com/Enalean/tuleap
author: Thomas Gerbet
author_date: 2018-03-01 14:40:05+01:00
msg: Merge 'gerrit #10714' into stable/master

* commit 'd6701289ae':
  request #11217 Account takeover due to a missing CSRF protection

Change-Id: Id29f45cfa402f0cb378b9f257d1e7adb4b0d40be
repository: repo_url: https://github.com/Enalean/tuleap
repo_name: Enalean/tuleap
description: Tuleap is an Open Source Suite to improve management of software developments and collaboration. With a single web-based solution, project managers, developers & quality managers can easily build, deploy software projects.
repo_language: PHP
owner: Enalean
CVE-2018-10677 (published 2018-05-02T19:29Z)

The DecodeGifImg function in ngiflib.c in MiniUPnP ngiflib 0.4 lacks certain checks against width and height, which allows remote attackers to cause a denial of service (WritePixels heap-based buffer overflow and application crash) or possibly have unspecified other impact via a crafted GIF file.

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

Weakness information:
cwe_id: CWE-787
cwe_name: Out-of-bounds Write
description: The product writes data past the end, or before the beginning, of the intended buffer.
extended_description: 
            
            
             
			 
         
         

Fix information:
repo_url: https://github.com/miniupnp/ngiflib
commit_details: repo_url: https://github.com/miniupnp/ngiflib
author: Thomas Bernard
author_date: 2018-05-02 09:15:48+02:00
msg: check GIF image position and dimensions

fixes #1
repository: repo_url: https://github.com/miniupnp/ngiflib
repo_name: miniupnp/ngiflib
description: GIF picture format decoding library written in C
repo_language: C
owner: miniupnp
file_changes: filename: ngiflib.c
change_type: ModificationType.MODIFY
diff: @@ -408,6 +408,24 @@ static int DecodeGifImg(struct ngiflib_img * i) {
 	i->width = GetWord(i->parent);	/* SizeX   */
 	i->height = GetWord(i->parent);	/* SizeY   */
 
+	if((i->width > i->parent->width) || (i->height > i->parent->height)) {
+#if !defined(NGIFLIB_NO_FILE)
+		if(i->parent->log) fprintf(i->parent->log, "*** ERROR *** Image bigger than global GIF canvas !\n");
+#endif
+		return -1;
+	}
+	if((i->posX + i->width) > i->parent->width) {
+#if !defined(NGIFLIB_NO_FILE)
+		if(i->parent->log) fprintf(i->parent->log, "*** WARNING *** Adjusting X position\n");
+#endif
+		i->posX = i->parent->width - i->width;
+	}
+	if((i->posY + i->height) > i->parent->height) {
+#if !defined(NGIFLIB_NO_FILE)
+		if(i->parent->log) fprintf(i->parent->log, "*** WARNING *** Adjusting Y position\n");
+#endif
+		i->posY = i->parent->height - i->height;
+	}
 	context.Xtogo = i->width;
 	context.curY = i->posY;
 #ifdef NGIFLIB_INDEXED_ONLY

programming_language: C
CVE-2021-36085 (published 2021-07-01T03:15Z)

The CIL compiler in SELinux 3.2 has a use-after-free in __cil_verify_classperms (called from __verify_map_perm_classperms and hashtab_map).

Severity: LOW
CVSS v2 base score: 2.1 (AV:L/AC:L/Au:N/C:N/I:N/A:P)
CVSS v3 base score: 3.3, LOW (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L)

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/SELinuxProject/selinux
commit_details: repo_url: https://github.com/SELinuxProject/selinux
author: James Carter
author_date: 2021-04-08 13:32:04-04:00
msg: libsepol/cil: Destroy classperm list when resetting map perms

Map perms share the same struct as regular perms, but only the
map perms use the classperms field. This field is a pointer to a
list of classperms that is created and added to when resolving
classmapping rules, so the map permission doesn't own any of the
data in the list and this list should be destroyed when the AST is
reset.

When resetting a perm, destroy the classperms list without destroying
the data in the list.

Signed-off-by: James Carter <jwcart2@gmail.com>
repository: repo_url: https://github.com/SELinuxProject/selinux
repo_name: SELinuxProject/selinux
description: This is the upstream repository for the Security Enhanced Linux (SELinux) userland libraries and tools. The software provided by this project complements the SELinux features integrated into the Linux kernel and is used by Linux distributions. All bugs and patches should be submitted to selinux@vger.kernel.org
repo_language: C
owner: SELinuxProject
file_changes: filename: cil_reset_ast.c
change_type: ModificationType.MODIFY
diff: @@ -36,7 +36,7 @@ static void cil_reset_class(struct cil_class *class)
 
 static void cil_reset_perm(struct cil_perm *perm)
 {
-	cil_reset_classperms_list(perm->classperms);
+	cil_list_destroy(&perm->classperms, CIL_FALSE);
 }
 
 static inline void cil_reset_classperms(struct cil_classperms *cp)

programming_language: C
CVE-2022-21671 (published 2022-01-11T15:15Z)

@replit/crosis is a JavaScript client that speaks Replit's container protocol. A vulnerability that involves exposure of sensitive information exists in versions prior to 7.3.1. When using this library as a way to programmatically communicate with Replit in a standalone fashion, if there are multiple failed attempts to contact Replit through a WebSocket, the library will attempt to communicate using a fallback poll-based proxy. The URL of the proxy has changed, so any communication done to the previous URL could potentially reach a server that is outside of Replit's control and the token used to connect to the Repl could be obtained by an attacker, leading to full compromise of that Repl (not of the account). This was patched in version 7.3.1 by updating the address of the fallback WebSocket polling proxy to the new one. As a workaround, a user may specify the new address for the polling host (`gp-v2.replit.com`) in the `ConnectArgs`. More information about this workaround is available in the GitHub Security Advisory.

Severity: MEDIUM
CVSS v2 base score: 4.0 (AV:N/AC:L/Au:S/C:P/I:N/A:N)
CVSS v3 base score: 6.5, MEDIUM (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/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/replit/crosis
commit_details: repo_url: https://github.com/replit/crosis
author: lhchavez
author_date: 2022-01-07 14:04:31-08:00
msg: Change the default polling host to `gp-v2.replit.com` (#113)

We switched the host a few days ago, so it's better to reflect reality.

This changes the default polling host to `gp-v2.replit.com`.
repository: repo_url: https://github.com/replit/crosis
repo_name: replit/crosis
description: A JavaScript client that speaks Replit's container protocol 
repo_language: TypeScript
owner: replit
file_changes: filename: CHANGELOG.md
change_type: ModificationType.MODIFY
diff: @@ -1,3 +1,7 @@
+#### v7.3.1
+
+Changed the default polling host to gp-v2.replit.com.
+
 #### v7.3.0
 
 Added an optional `pollingHost` field to `ConnectOptions`. This allows callers to override the polling host from gp-v2.herokuapp.com to something else when the polling fallback is used.

programming_language: Markdown
filename: helpers.ts
change_type: ModificationType.MODIFY
diff: @@ -61,7 +61,7 @@ export function getConnectionStr(
 ): string {
   const gurl = urllib.parse(connectionMetadata.gurl);
   if (isPolling) {
-    const host = pollingHost ?? 'gp-v2.herokuapp.com';
+    const host = pollingHost ?? 'gp-v2.replit.com';
     gurl.hostname = host;
     gurl.host = host;
     gurl.pathname = `/wsv2/${connectionMetadata.token}/${encodeURIComponent(

programming_language: TypeScript
CVE-2006-5331 (published 2017-10-29T06:29Z)

The altivec_unavailable_exception function in arch/powerpc/kernel/traps.c in the Linux kernel before 2.6.19 on 64-bit systems mishandles the case where CONFIG_ALTIVEC is defined and the CPU actually supports Altivec, but the Altivec support was not detected by the kernel, which allows local users to cause a denial of service (panic) by triggering execution of an Altivec instruction.

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

Weakness information:
cwe_id: CWE-19
cwe_name: Data Processing Errors
description: Weaknesses in this category are typically found in functionality that processes data. Data processing is the manipulation of input to retrieve or save information.

Fix information:
repo_url: https://github.com/torvalds/linux
commit_details: repo_url: https://github.com/torvalds/linux
author: Anton Blanchard
author_date: 2006-10-13 11:41:00+10:00
msg: [POWERPC] Never panic when taking altivec exceptions from userspace

At the moment we rely on a cpu feature bit or a firmware property to
detect altivec. If we dont have either of these and the cpu does in fact
support altivec we can cause a panic from userspace.

It seems safer to always send a signal if we manage to get an 0xf20
exception from userspace.

Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
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: traps.c
change_type: ModificationType.MODIFY
diff: @@ -900,14 +900,13 @@ void kernel_fp_unavailable_exception(struct pt_regs *regs)
 
 void altivec_unavailable_exception(struct pt_regs *regs)
 {
-#if !defined(CONFIG_ALTIVEC)
 	if (user_mode(regs)) {
 		/* A user program has executed an altivec instruction,
 		   but this kernel doesn't support altivec. */
 		_exception(SIGILL, regs, ILL_ILLOPC, regs->nip);
 		return;
 	}
-#endif
+
 	printk(KERN_EMERG "Unrecoverable VMX/Altivec Unavailable Exception "
 			"%lx at %lx\n", regs->trap, regs->nip);
 	die("Unrecoverable VMX/Altivec Unavailable Exception", regs, SIGABRT);

programming_language: C