hitoshura25/cvefixes huggingface dataset:
CVE-2024-31581 (C, published 2024-04-17T19:15Z)
Description: value: FFmpeg version n6.1 was discovered to contain an improper validation of array index vulnerability in libavcodec/cbs_h266_syntax_template.c. This vulnerability allows attackers to cause undefined behavior within the application.
Severity: nan (CVSS v3 base score: )
Weakness: NVD-CWE-noinfo \u2014 Insufficient Information
There is insufficient information about the issue to classify it; details are unkown or unspecified.
Repository: https://github.com/ffmpeg/ffmpeg
Files changed:
libavcodec/cbs_h266_syntax_template.c
Commit message: avcodec/cbs_h266: more restrictive check on pps_tile_idx_delta_val

Fixes: out of array access
Fixes: 62603/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5837632490569728

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>


Vulnerable code:
                            -current->num_tiles_in_pic + 1,
                            current->num_tiles_in_pic - 1, 1, i);

Fixed code:
                        // Two conditions must be met:
                        // 1. −NumTilesInPic + 1 <= pps_tile_idx_delta_val[i] <= NumTilesInPic − 1
                        // 2. 0 <= tile_idx + pps_tile_idx_delta_val[i] <= NumTilesInPic − 1
                        // Combining these conditions yields: -tile_idx <= pps_tile_idx_delta_val[i] <= NumTilesInPic - 1 - tile_idx
                            -tile_idx, current->num_tiles_in_pic - 1 - tile_idx, 1, i);
CVE-2024-31582 (C, published 2024-04-17T19:15Z)
Description: value: FFmpeg version n6.1 was discovered to contain a heap buffer overflow vulnerability in the draw_block_rectangle function of libavfilter/vf_codecview.c. This vulnerability allows attackers to cause undefined behavior or a Denial of Service (DoS) via crafted input.
Severity: nan (CVSS v3 base score: )
Weakness: NVD-CWE-noinfo \u2014 Insufficient Information
There is insufficient information about the issue to classify it; details are unkown or unspecified.
Repository: https://github.com/ffmpeg/ffmpeg
Files changed:
libavfilter/vf_codecview.c
Commit message: avfilter/vf_codecview: fix heap buffer overflow

And improve the performance by a little bit.

Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>


Vulnerable code:

    for (int x = sx; x < sx + w; x++)
        buf[x] = color;

Fixed code:
CVE-2024-31585 (C, published 2024-04-17T19:15Z)
Description: value: FFmpeg version n5.1 to n6.1 was discovered to contain an Off-by-one Error vulnerability in libavfilter/avf_showspectrum.c. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted input.
Severity: nan (CVSS v3 base score: )
Weakness: NVD-CWE-noinfo \u2014 Insufficient Information
There is insufficient information about the issue to classify it; details are unkown or unspecified.
Repository: https://github.com/ffmpeg/ffmpeg
Files changed:
libavfilter/avf_showspectrum.c
Commit message: avfilter/avf_showspectrum: fix off by 1 error

Fixes: out of array access
Fixes: tickets/10749/poc15ffmpeg

Regression since: 81df787b53eb5c6433731f6eaaf7f2a94d8a8c80

Found-by: Zeng Yunxiang
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>


Vulnerable code:
            while (nb_frame <= s->nb_frames) {

Fixed code:
            while (nb_frame < s->nb_frames) {
CVE-2020-7041 (Other, published 2020-02-27T18:15Z)
Description: value: An issue was discovered in openfortivpn 1.11.0 when used with OpenSSL 1.0.2 or later. tunnel.c mishandles certificate validation because an X509_check_host negative error code is interpreted as a successful return value.
Severity: MEDIUM (CVSS v3 base score: 5.3)
Weakness: CWE-295 \u2014 Improper Certificate Validation
The product does not validate, or incorrectly validates, a certificate.
Repository: https://github.com/adrienverge/openfortivpn
Files changed:
CHANGELOG.md
configure.ac
Commit message: openfortivpn version 1.12.0


Vulnerable code:
AC_INIT([openfortivpn], [1.11.0])

Fixed code:
### 1.12.0

* [-] fix CVE-2020-7043: TLS Certificate CommonName NULL Byte Vulnerability
* [-] fix CVE-2020-7042: use of uninitialized memory in X509_check_host
* [-] fix CVE-2020-7041: incorrect use of X509_check_host (regarding return value).
* [-] always hide cleartest password in -vv output
* [+] add a clear warning about sensitive information in the debug output
* [+] add a hint in debug output when password is read from config file
* [-] fix segfault when connecting with empty password
* [+] use resolvconf if available to update resolv.conf file
* [~] replace semicolon by space in dns-suffix string

AC_INIT([openfortivpn], [1.12.0])
CVE-2020-7041 (C, published 2020-02-27T18:15Z)
Description: value: An issue was discovered in openfortivpn 1.11.0 when used with OpenSSL 1.0.2 or later. tunnel.c mishandles certificate validation because an X509_check_host negative error code is interpreted as a successful return value.
Severity: MEDIUM (CVSS v3 base score: 5.3)
Weakness: CWE-295 \u2014 Improper Certificate Validation
The product does not validate, or incorrectly validates, a certificate.
Repository: https://github.com/adrienverge/openfortivpn
Files changed:
src/tunnel.c
Commit message: correctly check return value of X509_check_host

CVE-2020-7041 incorrect use of X509_check_host (regarding return value)
is fixed with this commit.

The flaw came in with #242 and prevented proper host name verification
when openssl >= 1.0.2 was in use since openfortivpn 1.7.0.


Vulnerable code:
	if (X509_check_host(cert, common_name, FIELD_SIZE, 0, NULL))

Fixed code:
	// correctly check return value of X509_check_host
	if (X509_check_host(cert, common_name, FIELD_SIZE, 0, NULL) == 1)
CVE-2020-7042 (Other, published 2020-02-27T18:15Z)
Description: value: An issue was discovered in openfortivpn 1.11.0 when used with OpenSSL 1.0.2 or later. tunnel.c mishandles certificate validation because the hostname check operates on uninitialized memory. The outcome is that a valid certificate is never accepted (only a malformed certificate may be accepted).
Severity: MEDIUM (CVSS v3 base score: 5.3)
Weakness: CWE-295 \u2014 Improper Certificate Validation
The product does not validate, or incorrectly validates, a certificate.
Repository: https://github.com/adrienverge/openfortivpn
Files changed:
CHANGELOG.md
configure.ac
Commit message: openfortivpn version 1.12.0


Vulnerable code:
AC_INIT([openfortivpn], [1.11.0])

Fixed code:
### 1.12.0

* [-] fix CVE-2020-7043: TLS Certificate CommonName NULL Byte Vulnerability
* [-] fix CVE-2020-7042: use of uninitialized memory in X509_check_host
* [-] fix CVE-2020-7041: incorrect use of X509_check_host (regarding return value).
* [-] always hide cleartest password in -vv output
* [+] add a clear warning about sensitive information in the debug output
* [+] add a hint in debug output when password is read from config file
* [-] fix segfault when connecting with empty password
* [+] use resolvconf if available to update resolv.conf file
* [~] replace semicolon by space in dns-suffix string

AC_INIT([openfortivpn], [1.12.0])
CVE-2020-7042 (Other, published 2020-02-27T18:15Z)
Description: value: An issue was discovered in openfortivpn 1.11.0 when used with OpenSSL 1.0.2 or later. tunnel.c mishandles certificate validation because the hostname check operates on uninitialized memory. The outcome is that a valid certificate is never accepted (only a malformed certificate may be accepted).
Severity: MEDIUM (CVSS v3 base score: 5.3)
Weakness: CWE-908 \u2014 Use of Uninitialized Resource
The product uses or accesses a resource that has not been initialized.
Repository: https://github.com/adrienverge/openfortivpn
Files changed:
CHANGELOG.md
configure.ac
Commit message: openfortivpn version 1.12.0


Vulnerable code:
AC_INIT([openfortivpn], [1.11.0])

Fixed code:
### 1.12.0

* [-] fix CVE-2020-7043: TLS Certificate CommonName NULL Byte Vulnerability
* [-] fix CVE-2020-7042: use of uninitialized memory in X509_check_host
* [-] fix CVE-2020-7041: incorrect use of X509_check_host (regarding return value).
* [-] always hide cleartest password in -vv output
* [+] add a clear warning about sensitive information in the debug output
* [+] add a hint in debug output when password is read from config file
* [-] fix segfault when connecting with empty password
* [+] use resolvconf if available to update resolv.conf file
* [~] replace semicolon by space in dns-suffix string

AC_INIT([openfortivpn], [1.12.0])
CVE-2020-7042 (C, published 2020-02-27T18:15Z)
Description: value: An issue was discovered in openfortivpn 1.11.0 when used with OpenSSL 1.0.2 or later. tunnel.c mishandles certificate validation because the hostname check operates on uninitialized memory. The outcome is that a valid certificate is never accepted (only a malformed certificate may be accepted).
Severity: MEDIUM (CVSS v3 base score: 5.3)
Weakness: CWE-295 \u2014 Improper Certificate Validation
The product does not validate, or incorrectly validates, a certificate.
Repository: https://github.com/adrienverge/openfortivpn
Files changed:
src/tunnel.c
Commit message: supply proper input buffer to X509_check_host

CVE-2020-7042 use of uninitialized memory in X509_check_host is fixed with
this commit

the uninitialized buffer common_name was passed as argument to X509_check_host
which prevented proper host name validation when openssl >= 1.0.2 was in use.
This came in with #282 which went into openfortivpn 1.7.1.
Unfortunately, this problem has stayed unnoticed because the return value
was not properly checked either (which is a separate issue, with CVE-2020-7041,
and which has been fixed by the previous commit)


Vulnerable code:
	char common_name[FIELD_SIZE + 1];
	// correctly check return value of X509_check_host
	if (X509_check_host(cert, common_name, FIELD_SIZE, 0, NULL) == 1)

Fixed code:
	// compare against gateway_host and correctly check return value
	// to fix piror Incorrect use of X509_check_host
	if (X509_check_host(cert, tunnel->config->gateway_host,
	                    0, 0, NULL) == 1)
	char common_name[FIELD_SIZE + 1];
CVE-2020-7042 (C, published 2020-02-27T18:15Z)
Description: value: An issue was discovered in openfortivpn 1.11.0 when used with OpenSSL 1.0.2 or later. tunnel.c mishandles certificate validation because the hostname check operates on uninitialized memory. The outcome is that a valid certificate is never accepted (only a malformed certificate may be accepted).
Severity: MEDIUM (CVSS v3 base score: 5.3)
Weakness: CWE-908 \u2014 Use of Uninitialized Resource
The product uses or accesses a resource that has not been initialized.
Repository: https://github.com/adrienverge/openfortivpn
Files changed:
src/tunnel.c
Commit message: supply proper input buffer to X509_check_host

CVE-2020-7042 use of uninitialized memory in X509_check_host is fixed with
this commit

the uninitialized buffer common_name was passed as argument to X509_check_host
which prevented proper host name validation when openssl >= 1.0.2 was in use.
This came in with #282 which went into openfortivpn 1.7.1.
Unfortunately, this problem has stayed unnoticed because the return value
was not properly checked either (which is a separate issue, with CVE-2020-7041,
and which has been fixed by the previous commit)


Vulnerable code:
	char common_name[FIELD_SIZE + 1];
	// correctly check return value of X509_check_host
	if (X509_check_host(cert, common_name, FIELD_SIZE, 0, NULL) == 1)

Fixed code:
	// compare against gateway_host and correctly check return value
	// to fix piror Incorrect use of X509_check_host
	if (X509_check_host(cert, tunnel->config->gateway_host,
	                    0, 0, NULL) == 1)
	char common_name[FIELD_SIZE + 1];
CVE-2020-7043 (Other, published 2020-02-27T18:15Z)
Description: value: An issue was discovered in openfortivpn 1.11.0 when used with OpenSSL before 1.0.2. tunnel.c mishandles certificate validation because hostname comparisons do not consider '\0' characters, as demonstrated by a good.example.com\x00evil.example.com attack.
Severity: MEDIUM (CVSS v3 base score: 9.1)
Weakness: CWE-295 \u2014 Improper Certificate Validation
The product does not validate, or incorrectly validates, a certificate.
Repository: https://github.com/adrienverge/openfortivpn
Files changed:
CHANGELOG.md
configure.ac
Commit message: openfortivpn version 1.12.0


Vulnerable code:
AC_INIT([openfortivpn], [1.11.0])

Fixed code:
### 1.12.0

* [-] fix CVE-2020-7043: TLS Certificate CommonName NULL Byte Vulnerability
* [-] fix CVE-2020-7042: use of uninitialized memory in X509_check_host
* [-] fix CVE-2020-7041: incorrect use of X509_check_host (regarding return value).
* [-] always hide cleartest password in -vv output
* [+] add a clear warning about sensitive information in the debug output
* [+] add a hint in debug output when password is read from config file
* [-] fix segfault when connecting with empty password
* [+] use resolvconf if available to update resolv.conf file
* [~] replace semicolon by space in dns-suffix string

AC_INIT([openfortivpn], [1.12.0])
CVE-2021-32685 (JavaScript, published 2021-06-16T01:15Z)
Description: value: tEnvoy contains the PGP, NaCl, and PBKDF2 in node.js and the browser (hashing, random, encryption, decryption, signatures, conversions), used by TogaTech.org. In versions prior to 7.0.3, the `verifyWithMessage` method of `tEnvoyNaClSigningKey` always returns `true` for any signature that has a SHA-512 hash matching the SHA-512 hash of the message even if the signature was invalid. This issue is patched in version 7.0.3. As a workaround: In `tenvoy.js` under the `verifyWithMessage` method definition within the `tEnvoyNaClSigningKey` class, ensure that the return statement call to `this.verify` ends in `.verified`.
Severity: HIGH (CVSS v3 base score: 9.8)
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/TogaTech/tEnvoy
Files changed:
node/tenvoy.js
tenvoy.js
Commit message: Critical security fix in verifyWithMessage


Vulnerable code:
		return this.verify(signed, password) && _tEnvoy.util.bytesToHex(_nacl.hash(_tEnvoy.util.pack(message))) == _tEnvoy.util.bytesToHex(hash);
		return this.verify(signed, password) && _tEnvoy.util.bytesToHex(_nacl.hash(_tEnvoy.util.pack(message))) == _tEnvoy.util.bytesToHex(hash);

Fixed code:
		return this.verify(signed, password).verified && _tEnvoy.util.bytesToHex(_nacl.hash(_tEnvoy.util.pack(message))) == _tEnvoy.util.bytesToHex(hash);
		return this.verify(signed, password).verified && _tEnvoy.util.bytesToHex(_nacl.hash(_tEnvoy.util.pack(message))) == _tEnvoy.util.bytesToHex(hash);
CVE-2022-24795 (Unknown, published 2022-04-05T16:15Z)
Description: value: yajl-ruby is a C binding to the YAJL JSON parsing and generation library. The 1.x branch and the 2.x branch of `yajl` contain an integer overflow which leads to subsequent heap memory corruption when dealing with large (~2GB) inputs. The reallocation logic at `yajl_buf.c#L64` may result in the `need` 32bit integer wrapping to 0 when `need` approaches a value of 0x80000000 (i.e. ~2GB of data), which results in a reallocation of buf->alloc into a small heap chunk. These integers are declared as `size_t` in the 2.x branch of `yajl`, which practically prevents the issue from triggering on 64bit platforms, however this does not preclude this issue triggering on 32bit builds on which `size_t` is a 32bit integer. Subsequent population of this under-allocated heap chunk is based on the original buffer size, leading to heap memory corruption. This vulnerability mostly impacts process availability. Maintainers believe exploitation for arbitrary code execution is unlikely. A patch is available and anticipated to be part of yajl-ruby version 1.4.2. As a workaround, avoid passing large inputs to YAJL.
Severity: MEDIUM (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/brianmario/yajl-ruby
Files changed:
Commit message: Merge pull request #204 from eileencodes/fix-c-warnings

Fix c warnings

Vulnerable code:

Fixed code:
CVE-2022-24795 (Unknown, published 2022-04-05T16:15Z)
Description: value: yajl-ruby is a C binding to the YAJL JSON parsing and generation library. The 1.x branch and the 2.x branch of `yajl` contain an integer overflow which leads to subsequent heap memory corruption when dealing with large (~2GB) inputs. The reallocation logic at `yajl_buf.c#L64` may result in the `need` 32bit integer wrapping to 0 when `need` approaches a value of 0x80000000 (i.e. ~2GB of data), which results in a reallocation of buf->alloc into a small heap chunk. These integers are declared as `size_t` in the 2.x branch of `yajl`, which practically prevents the issue from triggering on 64bit platforms, however this does not preclude this issue triggering on 32bit builds on which `size_t` is a 32bit integer. Subsequent population of this under-allocated heap chunk is based on the original buffer size, leading to heap memory corruption. This vulnerability mostly impacts process availability. Maintainers believe exploitation for arbitrary code execution is unlikely. A patch is available and anticipated to be part of yajl-ruby version 1.4.2. As a workaround, avoid passing large inputs to YAJL.
Severity: MEDIUM (CVSS v3 base score: 7.5)
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/brianmario/yajl-ruby
Files changed:
Commit message: Merge pull request #204 from eileencodes/fix-c-warnings

Fix c warnings

Vulnerable code:

Fixed code:
CVE-2022-39298 (PHP, published 2022-10-12T23:15Z)
Description: value: MelisFront is the engine that displays website hosted on Melis Platform. It deals with showing pages, plugins, URL rewritting, search optimization and SEO, etc. Attackers can deserialize arbitrary data on affected versions of `melisplatform/melis-front`, and ultimately leads to the execution of arbitrary PHP code on the system. Conducting this attack does not require authentication. Users should immediately upgrade to `melisplatform/melis-front` >= 5.0.1. This issue was addressed by restricting allowed classes when deserializing user-controlled data.
Severity: nan (CVSS v3 base score: 9.8)
Weakness: CWE-502 \u2014 Deserialization of Untrusted Data
The product deserializes untrusted data without sufficiently verifying that the resulting data will be valid.
Repository: https://github.com/melisplatform/melis-front
Files changed:
src/Controller/MelisPluginRendererController.php
src/Navigation/MelisFrontNavigation.php
src/Service/MelisSiteConfigService.php
Commit message: added allowed_classes=false param to unserialize function and changed interop container to psr container


Vulnerable code:
            $pluginHardcodedConfig = unserialize($pluginHardcodedConfig);
use Interop\Container\ContainerInterface;
                                            $siteName => unserialize($dbConf['sconf_datas'])
                                                $siteId => unserialize($dbConf['sconf_datas'])

Fixed code:
            $pluginHardcodedConfig = unserialize($pluginHardcodedConfig, ['allowed_classes' => false]);
use Psr\Container\ContainerInterface;
                                            $siteName => unserialize($dbConf['sconf_datas'], ['allowed_classes' => false])
                                                $siteId => unserialize($dbConf['sconf_datas'], ['allowed_classes' => false])
CVE-2017-11594 (Other, published 2017-07-24T01:29Z)
Description: value: Cross-site scripting (XSS) vulnerability in the Markdown parser in Loomio before 1.8.0 allows remote attackers to inject arbitrary web script or HTML via non-sanitized Markdown content in a new thread or a thread comment.
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/loomio/loomio
Files changed:
angular/core/config/marked.coffee
Commit message: Ensure existing marked renderer code runs with customization (#4078)

* Ensure existing marked renderer code runs with customization

* Use noopener / noreferrer for marked links


Vulnerable code:
angular.module('loomioApp').config (markedProvider, renderProvider) ->
  markedProvider.setOptions
    gfm: true
    sanitize: true
    breaks: true
  markedProvider.setRenderer(renderProvider.$get(0).createRenderer())
angular.module('loomioApp').factory 'render', ->
  createRenderer: ->
    renderer = new marked.Renderer()
    renderer.link = (href, title, text) ->
      "<a href='#{href}' title='#{title || text}' target='_blank'>#{text}</a>"
    renderer.paragraph = @cook('p')
    renderer.listitem  = @cook('li')
    renderer.tablecell = @cook('td')
    renderer.heading   = @headerCook
    renderer

  headerCook: (text, level) ->
    text = emojione.shortnameToImage(text)
    "<h#{level}>#{text}</h#{level}>"

  cook: (tag) ->
    (text) ->
      text = emojione.shortnameToImage(text)
      text = text.replace(/\[\[@([a-zA-Z0-9]+)\]\]/g, "<a class='lmo-user-mention' href='/u/$1'>@$1</a>")
      "<#{tag}>#{text}</#{tag}>"

Fixed code:
angular.module('loomioApp').config (markedProvider) ->
  customRenderer = (opts) ->
    _super   = new marked.Renderer(opts)
    renderer = _.clone(_super)
    cook = (text) ->
      text = emojione.shortnameToImage(text)
      text = text.replace(/\[\[@([a-zA-Z0-9]+)\]\]/g, "<a class='lmo-user-mention' href='/u/$1'>@$1</a>")
      text

    renderer.paragraph = (text) -> _super.paragraph cook(text)
    renderer.listitem  = (text) -> _super.listitem  cook(text)
    renderer.tablecell = (text) -> _super.tablecell cook(text)

    renderer.heading   = (text, level) ->
      _super.heading(emojione.shortnameToImage(text), level, text)

    renderer.link      = (href, title, text) ->
      _super.link(href, title, text).replace('<a ', '<a rel="noopener noreferrer" target="_blank" ')

    renderer

  markedProvider.setRenderer customRenderer(gfm: true, sanitize: true, breaks: true)