starsofchance/CVEfixes_v1.0.8 huggingface dataset:
CVE-2018-8949 (published 2018-03-23T17:29Z)

An issue was discovered in app/Model/Attribute.php in MISP before 2.4.89. There is a critical API integrity bug, potentially allowing users to delete attributes of other events. A crafted edit for an event (without attribute UUIDs but attribute IDs set) could overwrite an existing attribute.

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

Weakness information:
cwe_id: CWE-749
cwe_name: Exposed Dangerous Method or Function
description: The product provides an Applications Programming Interface (API) or similar interface for interaction with external actors, but the interface includes a dangerous method or function that is not properly restricted.
extended_description: 
            This weakness can lead to a wide variety of resultant weaknesses, depending on the behavior of the exposed method. It can apply to any number of technologies and approaches, such as ActiveX controls, Java functions, IOCTLs, and so on.
            The exposure can occur in a few different ways:
            
               The function/method was never intended to be exposed to outside actors.
               The function/method was only intended to be accessible to a limited set of actors, such as Internet-based access from a single web site.
            
         
         

Fix information:
repo_url: https://github.com/MISP/MISP
commit_details: repo_url: https://github.com/MISP/MISP
author: iglocska
author_date: 2018-03-23 11:44:47+01:00
msg: fix: critical API integrity bug, potentially allowing users to delete attributes of other events

- a crafted edit for an event (without attribute UUIDs but attribute IDs set) could overwrite an existing attribute
repository: repo_url: https://github.com/MISP/MISP
repo_name: MISP/MISP
description: MISP (core software) - Open Source Threat Intelligence and Sharing Platform
repo_language: PHP
owner: MISP
file_changes: filename: Attribute.php
change_type: ModificationType.MODIFY
diff: @@ -3128,6 +3128,7 @@ class Attribute extends AppModel {
 			$attribute['data'] = $result['data'];
 			$attribute['value'] = $attribute['value'] . '|' . $result['md5'];
 		}
+		unset($attribute['id']);
 		if (isset($attribute['uuid'])) {
 			$existingAttribute = $this->find('first', array(
 				'conditions' => array('Attribute.uuid' => $attribute['uuid']),

programming_language: PHP
CVE-2017-13036 (published 2017-09-14T06:29Z)

The OSPFv3 parser in tcpdump before 4.9.2 has a buffer over-read in print-ospf6.c:ospf6_decode_v3().

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.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)

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

Fix information:
repo_url: https://github.com/the-tcpdump-group/tcpdump
commit_details: repo_url: https://github.com/the-tcpdump-group/tcpdump
author: Francois-Xavier Le Bail
author_date: 2017-03-24 00:55:18+01:00
msg: CVE-2017-13036/OSPFv3: Add a bounds check before fetching data

This fixes a buffer over-read discovered by Bhargava Shastry,
SecT/TU Berlin.

Add a test using the capture file supplied by the reporter(s), modified
so the capture file won't be rejected as an invalid capture.
repository: repo_url: https://github.com/the-tcpdump-group/tcpdump
repo_name: the-tcpdump-group/tcpdump
description: the TCPdump network dissector
repo_language: C
owner: the-tcpdump-group
file_changes: filename: print-ospf6.c
change_type: ModificationType.MODIFY
diff: @@ -735,6 +735,7 @@ ospf6_decode_v3(netdissect_options *ndo,
 	case OSPF_TYPE_HELLO: {
 		register const struct hello6 *hellop = (const struct hello6 *)((const uint8_t *)op + OSPF6HDR_LEN);
 
+		ND_TCHECK_32BITS(&hellop->hello_options);
 		ND_PRINT((ndo, "\n\tOptions [%s]",
 		          bittok2str(ospf6_option_values, "none",
 		          EXTRACT_32BITS(&hellop->hello_options))));

programming_language: C
filename: TESTLIST
change_type: ModificationType.MODIFY
diff: @@ -549,6 +549,7 @@ pim_header_asan-2	pim_header_asan-2.pcap		pim_header_asan-2.out	-v
 pim_header_asan-3	pim_header_asan-3.pcap		pim_header_asan-3.out	-v
 ip6_frag_asan		ip6_frag_asan.pcap		ip6_frag_asan.out	-v
 radius_attr_asan	radius_attr_asan.pcap		radius_attr_asan.out	-v
+ospf6_decode_v3_asan	ospf6_decode_v3_asan.pcap	ospf6_decode_v3_asan.out -v
 
 # RTP tests
 # fuzzed pcap

programming_language: Shell
filename: ospf6_decode_v3_asan.out
change_type: ModificationType.ADD
diff: @@ -0,0 +1,2 @@
+IP6 (class 0x76, flowlabel 0xf6701, hlim 109, next-header OSPF (89) payload length: 30311) 6767:6780:6767:a102:4:b6:5853:f040 > 1000:a32:8847:1::116: OSPFv3, Hello, length 30311
+	Router-ID 1.1.0.34, Area 0.255.2.2, Instance 82 [|ospf3]

programming_language: SQL
CVE-2019-1010315 (published 2019-07-11T20:15Z)

WavPack 5.1 and earlier is affected by: CWE 369: Divide by Zero. The impact is: Divide by zero can lead to sudden crash of a software/service that tries to parse a .wav file. The component is: ParseDsdiffHeaderConfig (dsdiff.c:282). The attack vector is: Maliciously crafted .wav file. The fixed version is: After commit https://github.com/dbry/WavPack/commit/4c0faba32fddbd0745cbfaf1e1aeb3da5d35b9fc.

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

Weakness information:
cwe_id: CWE-369
cwe_name: Divide By Zero
description: The product divides a value by zero.
extended_description: This weakness typically occurs when an unexpected value is provided to the product, or if an error occurs that is not properly detected. It frequently occurs in calculations involving physical dimensions such as size, length, width, and height.
         

Fix information:
repo_url: https://github.com/dbry/WavPack
commit_details: repo_url: https://github.com/dbry/WavPack
author: David Bryant
author_date: 2019-03-02 18:37:14-08:00
msg: issue #65: make sure DSDIFF files have a valid channel count
repository: repo_url: https://github.com/dbry/WavPack
repo_name: dbry/WavPack
description: WavPack encode/decode library, command-line programs, and several plugins
repo_language: C
owner: dbry
file_changes: filename: dsdiff.c
change_type: ModificationType.MODIFY
diff: @@ -180,7 +180,7 @@ int ParseDsdiffHeaderConfig (FILE *infile, char *infilename, char *fourcc, Wavpa
 
             if (!strncmp (prop_chunk, "SND ", 4)) {
                 char *cptr = prop_chunk + 4, *eptr = prop_chunk + dff_chunk_header.ckDataSize;
-                uint16_t numChannels, chansSpecified, chanMask = 0;
+                uint16_t numChannels = 0, chansSpecified, chanMask = 0;
                 uint32_t sampleRate;
 
                 while (eptr - cptr >= sizeof (dff_chunk_header)) {
@@ -204,7 +204,7 @@ int ParseDsdiffHeaderConfig (FILE *infile, char *infilename, char *fourcc, Wavpa
 
                             chansSpecified = (int)(dff_chunk_header.ckDataSize - sizeof (numChannels)) / 4;
 
-                            if (numChannels < chansSpecified || numChannels < 1) {
+                            if (numChannels < chansSpecified || numChannels < 1 || numChannels > 256) {
                                 error_line ("%s is not a valid .DFF file!", infilename);
                                 free (prop_chunk);
                                 return WAVPACK_SOFT_ERROR;
@@ -279,6 +279,12 @@ int ParseDsdiffHeaderConfig (FILE *infile, char *infilename, char *fourcc, Wavpa
             free (prop_chunk);
         }
         else if (!strncmp (dff_chunk_header.ckID, "DSD ", 4)) {
+
+            if (!config->num_channels) {
+                error_line ("%s is not a valid .DFF file!", infilename);
+                return WAVPACK_SOFT_ERROR;
+            }
+
             total_samples = dff_chunk_header.ckDataSize / config->num_channels;
             break;
         }

programming_language: C
CVE-2021-3984 (published 2021-12-01T11:15Z)

vim is vulnerable to Heap-based Buffer Overflow

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-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: 2021-11-19 19:41:13+00:00
msg: patch 8.2.3625: illegal memory access when C-indenting

Problem:    Illegal memory access when C-indenting.
Solution:   Also set the cursor column.
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: @@ -1637,10 +1637,10 @@ get_baseclass_amount(int col)
     static pos_T *
 find_start_brace(void)	    // XXX
 {
-    pos_T	cursor_save;
-    pos_T	*trypos;
-    pos_T	*pos;
-    static pos_T	pos_copy;
+    pos_T	    cursor_save;
+    pos_T	    *trypos;
+    pos_T	    *pos;
+    static pos_T    pos_copy;
 
     cursor_save = curwin->w_cursor;
     while ((trypos = findmatchlimit(NULL, '{', FM_BLOCKSTOP, 0)) != NULL)
@@ -1654,7 +1654,7 @@ find_start_brace(void)	    // XXX
 		       && (pos = ind_find_start_CORS(NULL)) == NULL) // XXX
 	    break;
 	if (pos != NULL)
-	    curwin->w_cursor.lnum = pos->lnum;
+	    curwin->w_cursor = *pos;
     }
     curwin->w_cursor = cursor_save;
     return trypos;

programming_language: C
filename: test_cindent.vim
change_type: ModificationType.MODIFY
diff: @@ -5314,4 +5314,16 @@ func Test_backslash_at_end_of_line()
   bwipe!
 endfunc
 
+func Test_find_brace_backwards()
+  " this was looking beyond the end of the line
+  new
+  norm R/*
+  norm o0{
+  norm o//
+  norm V{=
+  call assert_equal(['/*', '   0{', '//'], getline(1, 3))
+  bwipe!
+endfunc
+
+
 " vim: shiftwidth=2 sts=2 expandtab

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

programming_language: Ruby
CVE-2023-46928 (published 2023-11-01T15:15Z)

GPAC 2.3-DEV-rev605-gfc9e29089-master contains a SEGV in gpac/MP4Box in gf_media_change_pl /afltest/gpac/src/media_tools/isom_tools.c:3293:42.

CVSS v3 base score: 5.5, MEDIUM (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/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/gpac/gpac
commit_details: repo_url: https://github.com/gpac/gpac
author: Aurelien David
author_date: 2023-10-26 12:27:53+02:00
msg: null guard on gf_media_change_pl (fixes #2661)
repository: repo_url: https://github.com/gpac/gpac
repo_name: gpac/gpac
description: GPAC Ultramedia OSS for Video Streaming & Next-Gen Multimedia Transcoding, Packaging & Delivery
repo_language: C
owner: gpac
file_changes: filename: isom_tools.c
change_type: ModificationType.MODIFY
diff: @@ -635,7 +635,7 @@ GF_Err gf_media_make_isma(GF_ISOFile *mp4file, Bool keepESIDs, Bool keepImage, B
 
 	_esd = gf_odf_desc_esd_new(SLPredef_MP4);
 	if (!_esd) return GF_OUT_OF_MEM;
-	
+
 	_esd->decoderConfig->bufferSizeDB = 20;
 	_esd->decoderConfig->objectTypeIndication = GF_CODECID_BIFS_V2;
 	_esd->decoderConfig->streamType = GF_STREAM_SCENE;
@@ -3289,6 +3289,10 @@ GF_Err gf_media_change_pl(GF_ISOFile *file, u32 track, u32 profile, u32 compat,
 	}
 
 	avcc = gf_isom_avc_config_get(file, track, 1);
+
+	if (!avcc)
+		return GF_NON_COMPLIANT_BITSTREAM;
+
 	if (level) avcc->AVCLevelIndication = level;
 	if (compat) avcc->profile_compatibility = compat;
 	if (profile) avcc->AVCProfileIndication = profile;

programming_language: C
CVE-2018-17293 (published 2018-09-21T07:29Z)

An issue was discovered in WAVM before 2018-09-16. The run function in Programs/wavm/wavm.cpp does not check whether there is Emscripten memory to store the command-line arguments passed by the input WebAssembly file's main function, which allows attackers to cause a denial of service (application crash by NULL pointer dereference) or possibly have unspecified other impact by crafting certain WebAssembly files.

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-476
cwe_name: NULL Pointer Dereference
description: The product dereferences a pointer that it expects to be valid but is NULL.
extended_description: 
            
            
            
         
         

Fix information:
repo_url: https://github.com/WAVM/WAVM
commit_details: repo_url: https://github.com/WAVM/WAVM
author: Andrew Scheidecker
author_date: 2018-09-16 09:55:34-04:00
msg: Fix dereferencing null pointer when running wavm with WebAssembly main function that takes command-line arguments but no Emscripten memory to write them to
repository: repo_url: https://github.com/WAVM/WAVM
repo_name: WAVM/WAVM
description: WebAssembly Virtual Machine
repo_language: C++
owner: WAVM
file_changes: filename: wavm.cpp
change_type: ModificationType.MODIFY
diff: @@ -250,21 +250,23 @@ static int run(const CommandLineOptions& options)
 	{
 		if(functionType.params().size() == 2)
 		{
-			MemoryInstance* defaultMemory = Runtime::getDefaultMemory(moduleInstance);
-			if(!defaultMemory)
+			if(!emscriptenInstance)
 			{
 				Log::printf(
 					Log::error,
 					"Module does not declare a default memory object to put arguments in.\n");
 				return EXIT_FAILURE;
 			}
+			else
+			{
+				std::vector<const char*> argStrings;
+				argStrings.push_back(options.filename);
+				char** args = options.args;
+				while(*args) { argStrings.push_back(*args++); };
 
-			std::vector<const char*> argStrings;
-			argStrings.push_back(options.filename);
-			char** args = options.args;
-			while(*args) { argStrings.push_back(*args++); };
-
-			Emscripten::injectCommandArgs(emscriptenInstance, argStrings, invokeArgs);
+				wavmAssert(emscriptenInstance);
+				Emscripten::injectCommandArgs(emscriptenInstance, argStrings, invokeArgs);
+			}
 		}
 		else if(functionType.params().size() > 0)
 		{

programming_language: C++
CVE-2013-7013 (published 2013-12-09T16:36Z)

The g2m_init_buffers function in libavcodec/g2meet.c in FFmpeg before 2.1 uses an incorrect ordering of arithmetic operations, which allows remote attackers to cause a denial of service (out-of-bounds array access) or possibly have unspecified other impact via crafted Go2Webinar data.

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

Weakness information:
cwe_id: CWE-189
cwe_name: Numeric Errors
description: Weaknesses in this category are related to improper calculation or conversion of numbers.

Fix information:
repo_url: https://github.com/FFmpeg/FFmpeg
commit_details: repo_url: https://github.com/FFmpeg/FFmpeg
author: Michael Niedermayer
author_date: 2013-09-15 16:33:27+02:00
msg: avcodec/g2meet: Fix order of align and pixel size multiplication.

Fixes out of array accesses
Fixes Ticket2922

Found-by: ami_stuff
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
repository: repo_url: https://github.com/FFmpeg/FFmpeg
repo_name: FFmpeg/FFmpeg
description: Mirror of https://git.ffmpeg.org/ffmpeg.git
repo_language: C
owner: FFmpeg
file_changes: filename: g2meet.c
change_type: ModificationType.MODIFY
diff: @@ -453,7 +453,7 @@ static int g2m_init_buffers(G2MContext *c)
     if (!c->synth_tile || !c->jpeg_tile ||
         c->old_tile_w < c->tile_width ||
         c->old_tile_h < c->tile_height) {
-        c->tile_stride = FFALIGN(c->tile_width * 3, 16);
+        c->tile_stride = FFALIGN(c->tile_width, 16) * 3;
         aligned_height = FFALIGN(c->tile_height,    16);
         av_free(c->synth_tile);
         av_free(c->jpeg_tile);

programming_language: C
CVE-2015-1333 (published 2015-08-31T10:59Z)

Memory leak in the __key_link_end function in security/keys/keyring.c in the Linux kernel before 4.1.4 allows local users to cause a denial of service (memory consumption) via many add_key system calls that refer to existing keys.

Severity: MEDIUM
CVSS v2 base score: 4.9 (AV:L/AC:L/Au:N/C:N/I:N/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: Colin Ian King
author_date: 2015-07-27 15:23:43+01:00
msg: KEYS: ensure we free the assoc array edit if edit is valid

__key_link_end is not freeing the associated array edit structure
and this leads to a 512 byte memory leak each time an identical
existing key is added with add_key().

The reason the add_key() system call returns okay is that
key_create_or_update() calls __key_link_begin() before checking to see
whether it can update a key directly rather than adding/replacing - which
it turns out it can.  Thus __key_link() is not called through
__key_instantiate_and_link() and __key_link_end() must cancel the edit.

CVE-2015-1333

Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: James Morris <james.l.morris@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: keyring.c
change_type: ModificationType.MODIFY
diff: @@ -1181,9 +1181,11 @@ void __key_link_end(struct key *keyring,
 	if (index_key->type == &key_type_keyring)
 		up_write(&keyring_serialise_link_sem);
 
-	if (edit && !edit->dead_leaf) {
-		key_payload_reserve(keyring,
-				    keyring->datalen - KEYQUOTA_LINK_BYTES);
+	if (edit) {
+		if (!edit->dead_leaf) {
+			key_payload_reserve(keyring,
+				keyring->datalen - KEYQUOTA_LINK_BYTES);
+		}
 		assoc_array_cancel_edit(edit);
 	}
 	up_write(&keyring->sem);

programming_language: C
CVE-2018-19842 (published 2018-12-04T09:29Z)

getToken in libr/asm/p/asm_x86_nz.c in radare2 before 3.1.0 allows attackers to cause a denial of service (stack-based buffer over-read) via crafted x86 assembly data, as demonstrated by rasm2.

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

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

Fix information:
repo_url: https://github.com/radare/radare2
commit_details: repo_url: https://github.com/radare/radare2
author: radare
author_date: 2018-11-21 17:50:58+01:00
msg: Fix #12239 - crash in the x86.nz assembler ##asm (#12252)
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: asm_x86_nz.c
change_type: ModificationType.MODIFY
diff: @@ -4295,21 +4295,26 @@ LookupTable oplookup[] = {
 };
 
 static x86newTokenType getToken(const char *str, size_t *begin, size_t *end) {
+	if (*begin > strlen (str)) {
+		return TT_EOF;
+	}
 	// Skip whitespace
-	while (begin && isspace ((ut8)str[*begin])) {
+	while (begin && str[*begin] && isspace ((ut8)str[*begin])) {
 		++(*begin);
 	}
 
 	if (!str[*begin]) {                // null byte
 		*end = *begin;
 		return TT_EOF;
-	} else if (isalpha ((ut8)str[*begin])) {   // word token
+	}
+	if (isalpha ((ut8)str[*begin])) {   // word token
 		*end = *begin;
-		while (end && isalnum ((ut8)str[*end])) {
+		while (end && str[*end] && isalnum ((ut8)str[*end])) {
 			++(*end);
 		}
 		return TT_WORD;
-	} else if (isdigit ((ut8)str[*begin])) {   // number token
+	}
+	if (isdigit ((ut8)str[*begin])) {   // number token
 		*end = *begin;
 		while (end && isalnum ((ut8)str[*end])) {     // accept alphanumeric characters, because hex.
 			++(*end);

programming_language: C++
CVE-2019-19057 (published 2019-11-18T06:15Z)

Two memory leaks in the mwifiex_pcie_init_evt_ring() function in drivers/net/wireless/marvell/mwifiex/pcie.c in the Linux kernel through 5.3.11 allow attackers to cause a denial of service (memory consumption) by triggering mwifiex_map_pci_memory() failures, aka CID-d10dcb615c8e.

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-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: Navid Emamdoost
author_date: 2019-10-04 15:16:48-05:00
msg: mwifiex: pcie: Fix memory leak in mwifiex_pcie_init_evt_ring

In mwifiex_pcie_init_evt_ring, a new skb is allocated which should be
released if mwifiex_map_pci_memory() fails. The release for skb and
card->evtbd_ring_vbase is added.

Fixes: 0732484b47b5 ("mwifiex: separate ring initialization and ring creation routines")
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Acked-by: Ganapathi Bhat <gbhat@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.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: pcie.c
change_type: ModificationType.MODIFY
diff: @@ -687,8 +687,11 @@ static int mwifiex_pcie_init_evt_ring(struct mwifiex_adapter *adapter)
 		skb_put(skb, MAX_EVENT_SIZE);
 
 		if (mwifiex_map_pci_memory(adapter, skb, MAX_EVENT_SIZE,
-					   PCI_DMA_FROMDEVICE))
+					   PCI_DMA_FROMDEVICE)) {
+			kfree_skb(skb);
+			kfree(card->evtbd_ring_vbase);
 			return -1;
+		}
 
 		buf_pa = MWIFIEX_SKB_DMA_ADDR(skb);
 

programming_language: C