hitoshura25/cvefixes huggingface dataset:
CVE-2023-48237 (C, published 2023-11-16T23:15Z)
Description: value: Vim is an open source command line text editor. In affected versions when shifting lines in operator pending mode and using a very large value, it may be possible to overflow the size of integer. Impact is low, user interaction is required and a crash may not even happen in all situations. This issue has been addressed in commit `6bf131888` which has been included in version 9.0.2112. Users are advised to upgrade. There are no known workarounds for this vulnerability.
Severity: nan (CVSS v3 base score: 4.3)
Weakness: CWE-190 \u2014 Integer Overflow or Wraparound
The product performs a calculation that can
         produce an integer overflow or wraparound when the logic
         assumes that the resulting value will always be larger than
         the original value. This occurs when an integer value is
         incremented to a value that is too large to store in the
         associated representation. When this occurs, the value may
         become a very small or negative number.
Repository: https://github.com/vim/vim
Files changed:
src/ops.c
src/testdir/test_indent.vim
src/version.c
Commit message: patch 9.0.2112: [security]: overflow in shift_line

Problem:  [security]: overflow in shift_line
Solution: allow a max indent of INT_MAX

[security]: overflow in shift_line

When shifting lines in operator pending mode and using a very large
value, we may overflow the size of integer. Fix this by using a long
variable, testing if the result would be larger than INT_MAX and if so,
indent by INT_MAX value.

Special case: We cannot use long here, since on 32bit architectures (or
on Windows?), it typically cannot take larger values than a plain int,
so we have to use long long count, decide whether the resulting
multiplication of the shiftwidth value * amount is larger than INT_MAX
and if so, we will store INT_MAX as possible larges value in the long
long count variable.

Then we can safely cast it back to int when calling the functions to set
the indent (set_indent() or change_indent()). So this should be safe.

Add a test that when using a huge value in operator pending mode for
shifting, we will shift by INT_MAX

closes: #13535

Signed-off-by: Christian Brabandt <cb@256bit.org>


Vulnerable code:
    int		count;
    count = get_indent();	// get current indent
	    count += sw_val * amount;
	change_indent(INDENT_SET, count, FALSE, NUL, call_changed_bytes);
	(void)set_indent(count, call_changed_bytes ? SIN_CHANGED : 0);

Fixed code:
    long long	count;
    count = (long long)get_indent();	// get current indent
	{
	    if ((long long)sw_val * (long long)amount > INT_MAX - count)
		count = INT_MAX;
	    else
		count += (long long)sw_val * (long long)amount;
	}
	change_indent(INDENT_SET, (int)count, FALSE, NUL, call_changed_bytes);
	(void)set_indent((int)count, call_changed_bytes ? SIN_CHANGED : 0);
" Test for indenting with large amount, causes overflow
func Test_indent_overflow_count()
  new
  setl sw=8
  call setline(1, "abc")
  norm! V2147483647>
  " indents by INT_MAX
  call assert_equal(2147483647, indent(1))
  close!
endfunc

/**/
    2112,
CVE-2023-5344 (C, published 2023-10-02T20:15Z)
Description: value: Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1969.
Severity: nan (CVSS v3 base score: 7.5)
Weakness: CWE-122 \u2014 Heap-based Buffer Overflow
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().
Repository: https://github.com/vim/vim
Files changed:
src/message.c
src/testdir/test_crash.vim
src/version.c
Commit message: patch 9.0.1969: [security] buffer-overflow in trunc_string()

Problem:  buffer-overflow in trunc_string()
Solution: Add NULL at end of buffer

Currently trunc_string() assumes that when the string is too long,
buf[e-1] will always be writeable. But that assumption may not always be
true. The condition currently looks like this

    else if (e + 3 < buflen)
    [...]
    else
    {
	// can't fit in the "...", just truncate it
	buf[e - 1] = NUL;
    }

but this means, we may run into the last else clause with e still being
larger than buflen. So a buffer overflow occurs.

So instead of using `buf[e - 1]`, let's just always
truncate at `buf[buflen - 1]` which should always be writable.

Signed-off-by: Christian Brabandt <cb@256bit.org>


Vulnerable code:
	buf[e - 1] = NUL;

Fixed code:
	buf[buflen - 1] = NUL;
  let file = 'crash/vim_msg_trunc_poc'
  let args = printf(cmn_args, vim, file)
  call term_sendkeys(buf, args ..
    \ '  || echo "crash 8: [OK]" >> X_crash1_result.txt' .. "\<cr>")
  call TermWait(buf, 3000)

      \ 'crash 8: [OK]',
/**/
    1969,
CVE-2023-5441 (C, published 2023-10-05T21:15Z)
Description: value: NULL Pointer Dereference in GitHub repository vim/vim prior to 20d161ace307e28690229b68584f2d84556f8960.
Severity: nan (CVSS v3 base score: 5.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/vim/vim
Files changed:
src/gui.c
src/testdir/crash/crash_scrollbar
src/testdir/test_crash.vim
src/version.c
Commit message: patch 9.0.1992: [security] segfault in exmode

Problem:  segfault in exmode when redrawing
Solution: skip gui_scroll when exmode_active

Signed-off-by: Christian Brabandt <cb@256bit.org>


Vulnerable code:

Fixed code:
 * may eventually cause a redraw using updateWindow
    // don't redraw, LineOffset and similar are not valid!
    if (exmode_active)
	return FALSE;
" this goes to insert mode and presses key k_VerScrollbar which may cause a redraw in exmode, which used ot crash Vim
norm oùX
  let file = 'crash/crash_scrollbar'
  let args = printf(cmn_args, vim, file)
  call term_sendkeys(buf, args ..
    \ '  && echo "crash 9: [OK]" >> X_crash1_result.txt' .. "\<cr>")
  call TermWait(buf, 1000)

      \ 'crash 9: [OK]',
/**/
    1992,
CVE-2023-5535 (C, published 2023-10-11T20:15Z)
Description: value: Use After Free in GitHub repository vim/vim prior to v9.0.2010.
Severity: nan (CVSS v3 base score: 7.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/vim/vim
Files changed:
src/buffer.c
src/testdir/test_crash.vim
src/version.c
Commit message: patch 9.0.2010: [security] use-after-free from buf_contents_changed()

Problem:  [security] use-after-free from buf_contents_changed()
Solution: block autocommands

Signed-off-by: Christian Brabandt <cb@256bit.org>


Vulnerable code:

Fixed code:
    // We don't want to trigger autocommands now, they may have nasty
    // side-effects like wiping buffers
    block_autocmds();
    unblock_autocmds();

  let file = 'crash/editing_arg_idx_POC_1'
  let args = printf(cmn_args, vim, file)
  call term_sendkeys(buf, args ..
    \ '  || echo "crash 10: [OK]" >> X_crash1_result.txt' .. "\<cr>")
  call TermWait(buf, 1000)
  call delete('Xerr')
  call delete('@')

      \ 'crash 10: [OK]',
/**/
    2010,
CVE-2018-12030 (PHP, published 2018-06-15T16:29Z)
Description: value: Chevereto Free before 1.0.13 has XSS.
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/Chevereto/Chevereto-Free
Files changed:
app/app.php
app/install/installer.php
app/routes/route.settings.php
app/themes/Peafowl/views/settings.php
Commit message: v1.0.13

Fixed post handling in /settings (name, bio)


Vulnerable code:
define('G_APP_VERSION', '1.0.12');
  
		
		
		
		
		
		
		
		
        
		
		
		
		
		
		
		
		
		
		
		$SAFE_POST = $handler::getVar('safe_post');	
		
		
		
			
			
			
				
					
					
                    
					
					
					
                    
                    
					
						
						
							
								
								
								
							
						
						
						$changed_email_message = _s('An email has been sent to %s with instructions to activate this email', $SAFE_POST['email']);	
						
						
						
						
						
					
				
				
					
				
					
				
					
					
				
			
			
			
					
						
						
							$handler::updateVar('safe_post', ['name' => CHV\User::sanitizeUserName($_POST['name'])]);
						
				
					
					
						
												
						
						
					
				
		
		
		
		
		
		
    
		
		
			
		
				
				
				
				
				
				
				
				
				
        
				
				
				
				
				<?php 
				
					if(in_array($zone[0], array("Africa", "America", "Antarctica", "Arctic", "Asia", "Atlantic", "Australia", "Europe", "Indian", "Pacific"))) {      
						} 
				
				
					
					
					
					
				
				
				
				
					]); ?>      
				
						<textarea name="bio" id="bio" class="resize-vertical" placeholder="<?php _se('Tell us a little bit about you'); ?>" maxlength="255"><?php echo get_safe_post() ? get_safe_post()["bio"] : get_user()["bio"]; ?></textarea>
				
				
				
				
				
				
				
				
				
			
	
    

Fixed code:
define('G_APP_VERSION', '1.0.13');
		'1.0.13' => NULL,




















		$SAFE_POST = $handler::getVar('safe_post');

























						$changed_email_message = _s('An email has been sent to %s with instructions to activate this email', $SAFE_POST['email']);





















							// 'name' gets sanitized on User::update, this update safe_post to reflect the actual value
							$handler::updateVar('safe_post', [
								'name' => G\safe_html($user['name']),
							]);



































				<?php

					if(in_array($zone[0], array("Africa", "America", "Antarctica", "Arctic", "Asia", "Atlantic", "Australia", "Europe", "Indian", "Pacific"))) {
						}










					]); ?>

						<textarea name="bio" id="bio" class="resize-vertical" placeholder="<?php _se('Tell us a little bit about you'); ?>" maxlength="255"><?php echo get_safe_post() ? get_safe_post()["bio"] : get_safe_html_user()["bio"]; ?></textarea>
CVE-2016-15016 (PHP, published 2023-01-08T18:15Z)
Description: value: A vulnerability was found in mrtnmtth joomla_mod_einsatz_stats up to 0.2. It has been classified as critical. This affects the function getStatsByType of the file helper.php. The manipulation of the argument year leads to sql injection. Upgrading to version 0.3 is able to address this issue. The identifier of the patch is 27c1b443cff45c81d9d7d926a74c76f8b6ffc6cb. It is recommended to upgrade the affected component. The identifier VDB-217653 was assigned to this vulnerability.
Severity: nan (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/mrtnmtth/joomla_mod_einsatz_stats
Files changed:
helper.php
Commit message: prevent SQL-injection


Vulnerable code:
			WHERE berichte.state=1 AND berichte.date1 LIKE \''.$year.'%\'
			//TODO mucho importante: Prevent SQL injection
		$data = $input->get('data');

Fixed code:
		$db = JFactory::getDbo();
			WHERE berichte.state=1 AND berichte.date1 LIKE '.$db->quote($year.'%').'
		// only allow unsigned integers
		$data = $input->get('data', date('Y'), 'UINT');
CVE-2017-2920 (C++, published 2017-10-05T19:29Z)
Description: value: An memory corruption vulnerability exists in the .SVG parsing functionality of Computerinsel Photoline 20.02. A specially crafted .SVG file can cause a vulnerability resulting in memory corruption, which can potentially lead to arbitrary code execution. An attacker can send a specific .SVG file to trigger this vulnerability.
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/libofx/libofx
Files changed:
lib/ofx_preproc.cpp
Commit message: Fix a buffer overflow.

This is only the minimum workaround to prevent buffer overflow:
Stop iterating once the (fixed!) size of the output buffers is
reached. In response to
https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0317

However, this code is a huge mess anyway and is in no way
anything like up-to-date C++ code. Please, anyone, replace it
with something more modern. Thanks.


Vulnerable code:
  size_t input_string_size;
  input_string_size = input_string.size();

  for (i = 0; i < input_string_size; i++)

Fixed code:
  size_t input_string_size = input_string.size();

  // Minimum workaround to prevent buffer overflow: Stop iterating
  // once the (fixed!) size of the output buffers is reached. In
  // response to
  // https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0317
  //
  // However, this code is a huge mess anyway and is in no way
  // anything like up-to-date C++ code. Please, anyone, replace it
  // with something more modern. Thanks. - cstim, 2017-09-17.
  for (i = 0; i < std::min(input_string_size, size_t(READ_BUFFER_SIZE)); i++)
CVE-2022-4514 (Unknown, published 2022-12-15T20:15Z)
Description: value: A vulnerability, which was classified as problematic, was found in Opencaching Deutschland oc-server3. Affected is an unknown function of the file htdocs/lang/de/ocstyle/varset.inc.php. The manipulation of the argument varvalue leads to cross site scripting. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. The name of the patch is 4bdd6a0e7b7760cea03b91812cbb80d7b16e3b5f. It is recommended to apply a patch to fix this issue. VDB-215886 is the identifier assigned to this vulnerability.
Severity: nan (CVSS v3 base score: 6.1)
Weakness: CWE-79 \u2014 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.
Repository: https://github.com/OpencachingDeutschland/oc-server3
Files changed:
Commit message: Merge pull request #902 from sdennler/fix/open-bug-bounty-issues-2

Fix XSS from open bug bounty from slack message 01

Vulnerable code:

Fixed code:
CVE-2022-4585 (PHP, published 2022-12-17T13:15Z)
Description: value: A vulnerability classified as problematic has been found in Opencaching Deutschland oc-server3. This affects an unknown part of the file htdocs/templates2/ocstyle/start.tpl of the component Cookie Handler. The manipulation of the argument usercountryCode leads to cross site scripting. It is possible to initiate the attack remotely. The name of the patch is c720f2777a452186c67ef30db3679dd409556544. It is recommended to apply a patch to fix this issue. The associated identifier of this vulnerability is VDB-216171.
Severity: nan (CVSS v3 base score: 6.1)
Weakness: CWE-79 \u2014 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.
Repository: https://github.com/OpencachingDeutschland/oc-server3
Files changed:
htdocs/lib2/common.inc.php
htdocs/templates2/ocstyle/start.tpl
Commit message: Fix XSS on home page (OBB-602216)
Do not store totaly invalid countries in cookie in the first place


Vulnerable code:
    if (isset($_REQUEST['usercountry'])) {
                <a href="newcaches.php?country={$usercountryCode}"

Fixed code:
    if (preg_match('/^[a-z]{2}$/i', $_REQUEST['usercountry'] ?? '')) {
                <a href="newcaches.php?country={$usercountryCode|escape}"
CVE-2022-4586 (Other, published 2022-12-17T13:15Z)
Description: value: A vulnerability classified as problematic was found in Opencaching Deutschland oc-server3. This vulnerability affects unknown code of the file htdocs/templates2/ocstyle/cachelists.tpl of the component Cachelist Handler. The manipulation of the argument name_filter/by_filter leads to cross site scripting. The attack can be initiated remotely. The name of the patch is a9f79c7da78cd24a7ef1d298e6bc86006972ea73. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-216172.
Severity: nan (CVSS v3 base score: 6.1)
Weakness: CWE-79 \u2014 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.
Repository: https://github.com/OpencachingDeutschland/oc-server3
Files changed:
htdocs/templates2/ocstyle/cachelists.tpl
Commit message: Fix XSS in cachelists (OBB-217897)


Vulnerable code:
                        <td><input id="name_filter" name="name" value="{$name_filter}" class="input170" /></td>
                        <td><input id="by_filter" name="by" value="{$by_filter}" class="input170" /></td>

Fixed code:
                        <td><input id="name_filter" name="name" value="{$name_filter|escape}" class="input170" /></td>
                        <td><input id="by_filter" name="by" value="{$by_filter|escape}" class="input170" /></td>
CVE-2022-4587 (Other, published 2022-12-17T13:15Z)
Description: value: A vulnerability, which was classified as problematic, has been found in Opencaching Deutschland oc-server3. This issue affects some unknown processing of the file htdocs/templates2/ocstyle/login.tpl of the component Login Page. The manipulation of the argument username leads to cross site scripting. The attack may be initiated remotely. The name of the patch is 3296ebd61e7fe49e93b5755d5d7766d6e94a7667. It is recommended to apply a patch to fix this issue. The identifier VDB-216173 was assigned to this vulnerability.
Severity: nan (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/OpencachingDeutschland/oc-server3
Files changed:
htdocs/templates2/ocstyle/login.tpl
Commit message: Fix XSS on login page (OBB-1146814)


Vulnerable code:
            <td><input name="email" maxlength="80" type="text" value="{$username}" class="input200" /></td>

Fixed code:
<h1>login.tpl</h1>
            <td><input name="email" maxlength="80" type="text" value="{$username|escape}" class="input200" /></td>
CVE-2018-7711 (PHP, published 2018-03-05T22:29Z)
Description: value: HTTPRedirect.php in the saml2 library in SimpleSAMLphp before 1.15.4 has an incorrect check of return values in the signature validation utilities, allowing an attacker to get invalid signatures accepted as valid by forcing an error during validation. This occurs because of a dependency on PHP functionality that interprets a -1 error code as a true boolean value.
Severity: MEDIUM (CVSS v3 base score: 8.1)
Weakness: CWE-347 \u2014 Improper Verification of Cryptographic Signature
The product does not verify, or incorrectly verifies, the cryptographic signature for data.
Repository: https://github.com/simplesamlphp/saml2
Files changed:
src/SAML2/HTTPRedirect.php
Commit message: Be strict when checking return values.


Vulnerable code:
        if (!$key->verifySignature($query, $signature)) {

Fixed code:
        if ($key->verifySignature($query, $signature) !== 1) {
CVE-2021-46019 (Other, published 2022-01-14T20:15Z)
Description: value: An untrusted pointer dereference in rec_db_destroy() at rec-db.c of GNU Recutils v1.8.90 can lead to a segmentation fault or application crash.
Severity: MEDIUM (CVSS v3 base score: 5.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/gnu-mirror-unofficial/recutils
Files changed:
ChangeLog
src/rec-parser.c
Commit message: parser: avoid character 0xff being interpreted as (int) -1

This fixes the following CVEs:
- CVE-2021-46019
- CVE-2021-46022
- CVE-2021-46022

2022-04-16  Jose E. Marchesi  <jemarch@gnu.org>

	CVE-2021-46019
	CVE-2021-46022
	CVE-2021-46022
	* src/rec-parser.c (rec_parse_comment): Avoid 0xff being
	interpreted as (int) -1.


Vulnerable code:
          if (rec_buf_putc (c, buf) == EOF)

Fixed code:
2022-04-16  Jose E. Marchesi  <jemarch@gnu.org>

	CVE-2021-46019
	CVE-2021-46022
	CVE-2021-46022
	* src/rec-parser.c (rec_parse_comment): Avoid 0xff being
	interpreted as (int) -1.

          if (rec_buf_putc (ci, buf) == EOF)
CVE-2021-46022 (Other, published 2022-01-14T20:15Z)
Description: value: An Use-After-Free vulnerability in rec_mset_elem_destroy() at rec-mset.c of GNU Recutils v1.8.90 can lead to a segmentation fault or application crash.
Severity: MEDIUM (CVSS v3 base score: 5.5)
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/gnu-mirror-unofficial/recutils
Files changed:
ChangeLog
src/rec-parser.c
Commit message: parser: avoid character 0xff being interpreted as (int) -1

This fixes the following CVEs:
- CVE-2021-46019
- CVE-2021-46022
- CVE-2021-46022

2022-04-16  Jose E. Marchesi  <jemarch@gnu.org>

	CVE-2021-46019
	CVE-2021-46022
	CVE-2021-46022
	* src/rec-parser.c (rec_parse_comment): Avoid 0xff being
	interpreted as (int) -1.


Vulnerable code:
          if (rec_buf_putc (c, buf) == EOF)

Fixed code:
2022-04-16  Jose E. Marchesi  <jemarch@gnu.org>

	CVE-2021-46019
	CVE-2021-46022
	CVE-2021-46022
	* src/rec-parser.c (rec_parse_comment): Avoid 0xff being
	interpreted as (int) -1.

          if (rec_buf_putc (ci, buf) == EOF)
CVE-2015-8013 (JavaScript, published 2017-07-25T18:29Z)
Description: value: s2k.js in OpenPGP.js will decrypt arbitrary messages regardless of passphrase for crafted PGP keys which allows remote attackers to bypass authentication if message decryption is used as an authentication mechanism via a crafted symmetrically encrypted PGP message.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-310 \u2014 Cryptographic Issues
Weaknesses in this category are related to the design and implementation of data confidentiality and integrity. Frequently these deal with the use of encoding techniques, encryption libraries, and hashing algorithms. The weaknesses in this category could lead to a degradation of the quality data if they are not addressed.
Repository: https://github.com/openpgpjs/openpgpjs
Files changed:
src/type/s2k.js
Commit message: Throw exception on unsupported S2K type.


Vulnerable code:

Fixed code:
    case 'gnu':
      throw new Error("GNU s2k type not supported.");
    default:
      throw new Error("Unknown s2k type.");

      case 'gnu':
        throw new Error("GNU s2k type not supported.");

      default:
        throw new Error("Unknown s2k type.");