hitoshura25/cvefixes huggingface dataset:
CVE-2015-10024 (Go, published 2023-01-07T13:15Z)
Description: value: A vulnerability classified as critical was found in hoffie larasync. This vulnerability affects unknown code of the file repository/content/file_storage.go. The manipulation leads to path traversal. The name of the patch is 776bad422f4bd4930d09491711246bbeb1be9ba5. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-217612.
Severity: nan (CVSS v3 base score: 9.8)
Weakness: CWE-22 \u2014 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.
Repository: https://github.com/hoffie/larasync
Files changed:
repository/content/file_storage.go
repository/content/file_storage_test.go
Commit message: repository/content: fix potential (authenticated) path traversal (#195)


Vulnerable code:
func (f *FileStorage) storagePathFor(contentID string) string {
	return path.Join(f.path, contentID)
	if f.Exists(contentID) {
		return os.Open(f.storagePathFor(contentID))
	return nil, os.ErrNotExist
	blobStoragePath := f.storagePathFor(contentID)
	_, err := os.Stat(f.storagePathFor(contentID))
	return os.Remove(f.storagePathFor(contentID))

Fixed code:
	"errors"
	"path/filepath"
	"strings"
// ErrInvalidPath is returned if storage at a path not rooted at the FileStorage's
// root path is attempted.
var ErrInvalidPath = errors.New("invalid path")

func (f *FileStorage) storagePathFor(contentID string) (string, error) {
	p := path.Join(f.path, contentID)
	p = filepath.Clean(p)
	root := f.path
	/*if len(root) > 1 && root[len(root)-1] != filepath.Separator {
		root += filepath.Separator
	}*/
	if !strings.HasPrefix(p, root) {
		return "", ErrInvalidPath
	}
	return p, nil
	if !f.Exists(contentID) {
		return nil, os.ErrNotExist
	}
	// FIXME TOCTU race
	p, err := f.storagePathFor(contentID)
	if err != nil {
		return nil, err
	return os.Open(p)
	blobStoragePath, err := f.storagePathFor(contentID)
	if err != nil {
		return err
	}
	p, err := f.storagePathFor(contentID)
	if err != nil {
		// FIXME maybe return error instead?
		return false
	}
	_, err = os.Stat(p)
	p, err := f.storagePathFor(contentID)
	if err != nil {
		return err
	}
	return os.Remove(p)
var dangerousNames = []string{"..", "../xyz"}

func (t *FileStorageTests) TestSetDangerousName(c *C) {
	r := t.testReader()
	for _, id := range dangerousNames {
		err := t.storage.Set(id, r)
		c.Assert(err, NotNil)
	}
}

func (t *FileStorageTests) TestGetDangerousName(c *C) {
	for _, id := range dangerousNames {
		_, err := t.storage.Get(id)
		c.Assert(err, NotNil)
	}
}
CVE-2019-15691 (Other, published 2019-12-26T15:15Z)
Description: value: TigerVNC version prior to 1.10.1 is vulnerable to stack use-after-return, which occurs due to incorrect usage of stack memory in ZRLEDecoder. If decoding routine would throw an exception, ZRLEDecoder may try to access stack variable, which has been already freed during the process of stack unwinding. Exploitation of this vulnerability could potentially result into remote code execution. This attack appear to be exploitable via network connectivity.
Severity: MEDIUM (CVSS v3 base score: 7.2)
Weakness: CWE-672 \u2014 Operation on a Resource after Expiration or Release
The product uses, accesses, or otherwise operates on a resource after that resource has been expired, released, or revoked.
Repository: https://github.com/CendioOssman/tigervnc
Files changed:
common/rdr/ZlibInStream.cxx
common/rdr/ZlibInStream.h
common/rfb/CMsgReader.cxx
common/rfb/SMsgReader.cxx
common/rfb/TightDecoder.cxx
common/rfb/zrleDecode.h
Commit message: Make ZlibInStream more robust against failures

Move the checks around to avoid missing cases where we might access
memory that is no longer valid. Also avoid touching the underlying
stream implicitly (e.g. via the destructor) as it might also no
longer be valid.

A malicious server could theoretically use this for remote code
execution in the client.

Issue found by Pavel Cheremushkin from Kaspersky Lab


Vulnerable code:
void ZlibInStream::removeUnderlying()
  if (!underlying) return;
  underlying = 0;
  removeUnderlying();
  if (!underlying)
    throw Exception("ZlibInStream overrun: no underlying stream");
    void removeUnderlying();
    zis.removeUnderlying();
    zis.removeUnderlying();
    zis[streamId].removeUnderlying();
  zis->removeUnderlying();

Fixed code:
void ZlibInStream::flushUnderlying()

  setUnderlying(NULL, 0);
  setUnderlying(NULL, 0);
  if (!underlying)
    throw Exception("ZlibInStream overrun: no underlying stream");

    void flushUnderlying();
    zis.flushUnderlying();
    zis.setUnderlying(NULL, 0);
    zis.flushUnderlying();
    zis.setUnderlying(NULL, 0);
    zis[streamId].flushUnderlying();
    zis[streamId].setUnderlying(NULL, 0);
  zis->flushUnderlying();
  zis->setUnderlying(NULL, 0);
CVE-2019-15692 (Other, published 2019-12-26T15:15Z)
Description: value: TigerVNC version prior to 1.10.1 is vulnerable to heap buffer overflow. Vulnerability could be triggered from CopyRectDecoder due to incorrect value checks. Exploitation of this vulnerability could potentially result into remote code execution. This attack appear to be exploitable via network connectivity.
Severity: MEDIUM (CVSS v3 base score: 7.2)
Weakness: CWE-787 \u2014 Out-of-bounds Write
The product writes data past the end, or before the beginning, of the intended buffer.
Repository: https://github.com/CendioOssman/tigervnc
Files changed:
common/rfb/PixelBuffer.cxx
Commit message: Restrict PixelBuffer dimensions to safe values

We do a lot of calculations based on pixel coordinates and we need
to make sure they do not overflow. Restrict the maximum dimensions
we support rather than try to switch over all calculations to use
64 bit integers.

This prevents attackers from from injecting code by specifying a
huge framebuffer size and relying on the values overflowing to
access invalid areas of the heap.

This primarily affects the client which gets both the screen
dimensions and the pixel contents from the remote side. But the
server might also be affected as a client can adjust the screen
dimensions, as can applications inside the session.

Issue found by Pavel Cheremushkin from Kaspersky Lab.


Vulnerable code:

Fixed code:
// We do a lot of byte offset calculations that assume the result fits
// inside a signed 32 bit integer. Limit the maximum size of pixel
// buffers so that these calculations never overflow.

const int maxPixelBufferWidth = 16384;
const int maxPixelBufferHeight = 16384;
const int maxPixelBufferStride = 16384;

  if ((width < 0) || (width > maxPixelBufferWidth))
    throw rfb::Exception("Invalid PixelBuffer width of %d pixels requested", width);
  if ((height < 0) || (height > maxPixelBufferHeight))
    throw rfb::Exception("Invalid PixelBuffer height of %d pixels requested", height);

  if ((width < 0) || (width > maxPixelBufferWidth))
    throw rfb::Exception("Invalid PixelBuffer width of %d pixels requested", width);
  if ((height < 0) || (height > maxPixelBufferHeight))
    throw rfb::Exception("Invalid PixelBuffer height of %d pixels requested", height);
  if ((stride_ < 0) || (stride_ > maxPixelBufferStride) || (stride_ < width))
    throw rfb::Exception("Invalid PixelBuffer stride of %d pixels requested", stride_);
  if ((width != 0) && (height != 0) && (data_ == NULL))
    throw rfb::Exception("PixelBuffer requested without a valid memory area");
CVE-2019-15693 (C, published 2019-12-26T15:15Z)
Description: value: TigerVNC version prior to 1.10.1 is vulnerable to heap buffer overflow, which occurs in TightDecoder::FilterGradient. Exploitation of this vulnerability could potentially result into remote code execution. This attack appear to be exploitable via network connectivity.
Severity: MEDIUM (CVSS v3 base score: 7.2)
Weakness: CWE-787 \u2014 Out-of-bounds Write
The product writes data past the end, or before the beginning, of the intended buffer.
Repository: https://github.com/CendioOssman/tigervnc
Files changed:
common/rfb/tightDecode.h
Commit message: Handle empty Tight gradient rects

We always assumed there would be one pixel per row so a rect with
a zero width would result in us writing to unknown memory.

This could theoretically be used by a malicious server to inject
code in to the viewer process.

Issue found by Pavel Cheremushkin from Kaspersky Lab.


Vulnerable code:
    /* First pixel in a row */
    for (c = 0; c < 3; c++) {
      pix[c] = inbuf[y*rectWidth*3+c] + prevRow[c];
      thisRow[c] = pix[c];
    }
    pf.bufferFromRGB((rdr::U8*)&outbuf[y*stride], pix, 1);
    /* Remaining pixels of a row */
    for (x = 1; x < rectWidth; x++) {
    /* First pixel in a row */
    pf.rgbFromBuffer(pix, &inbuf[y*rectWidth], 1);
    for (c = 0; c < 3; c++)
      pix[c] += prevRow[c];
    memcpy(thisRow, pix, sizeof(pix));
    pf.bufferFromRGB((rdr::U8*)&outbuf[y*stride], pix, 1);
    /* Remaining pixels of a row */
    for (x = 1; x < rectWidth; x++) {

Fixed code:
    for (x = 0; x < rectWidth; x++) {
      /* First pixel in a row */
      if (x == 0) {
        for (c = 0; c < 3; c++) {
          pix[c] = inbuf[y*rectWidth*3+c] + prevRow[c];
          thisRow[c] = pix[c];
        }
        pf.bufferFromRGB((rdr::U8*)&outbuf[y*stride], pix, 1);
        continue;
      }
    for (x = 0; x < rectWidth; x++) {
      /* First pixel in a row */
      if (x == 0) {
        pf.rgbFromBuffer(pix, &inbuf[y*rectWidth], 1);
        for (c = 0; c < 3; c++)
          pix[c] += prevRow[c];
        memcpy(thisRow, pix, sizeof(pix));
        pf.bufferFromRGB((rdr::U8*)&outbuf[y*stride], pix, 1);

        continue;
      }
CVE-2019-15695 (Other, published 2019-12-26T16:15Z)
Description: value: TigerVNC version prior to 1.10.1 is vulnerable to stack buffer overflow, which could be triggered from CMsgReader::readSetCursor. This vulnerability occurs due to insufficient sanitization of PixelFormat. Since remote attacker can choose offset from start of the buffer to start writing his values, exploitation of this vulnerability could potentially result into remote code execution. This attack appear to be exploitable via network connectivity.
Severity: MEDIUM (CVSS v3 base score: 7.2)
Weakness: CWE-754 \u2014 Improper Check for Unusual or Exceptional Conditions
The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.
Repository: https://github.com/CendioOssman/tigervnc
Files changed:
common/rfb/PixelFormat.cxx
tests/unit/pixelformat.cxx
Commit message: Handle pixel formats with odd shift values

Our fast paths assume that each channel fits in to a separate byte.
That means the shift needs to be a multiple of 8. Start actually
checking this so that a client cannot trip us up and possibly cause
incorrect code exection.

Issue found by Pavel Cheremushkin from Kaspersky Lab.


Vulnerable code:

Fixed code:
  if ((redShift & 0x7) != 0)
    return false;
  if ((greenShift & 0x7) != 0)
    return false;
  if ((blueShift & 0x7) != 0)
    return false;
    /* Odd shifts */

    do888Test(false, 32, 24, false, true, 255, 255, 255, 0, 8, 18);
    do888Test(false, 32, 24, false, true, 255, 255, 255, 0, 11, 24);
    do888Test(false, 32, 24, false, true, 255, 255, 255, 4, 16, 24);
CVE-2019-15695 (Other, published 2019-12-26T16:15Z)
Description: value: TigerVNC version prior to 1.10.1 is vulnerable to stack buffer overflow, which could be triggered from CMsgReader::readSetCursor. This vulnerability occurs due to insufficient sanitization of PixelFormat. Since remote attacker can choose offset from start of the buffer to start writing his values, exploitation of this vulnerability could potentially result into remote code execution. This attack appear to be exploitable via network connectivity.
Severity: MEDIUM (CVSS v3 base score: 7.2)
Weakness: CWE-787 \u2014 Out-of-bounds Write
The product writes data past the end, or before the beginning, of the intended buffer.
Repository: https://github.com/CendioOssman/tigervnc
Files changed:
common/rfb/PixelFormat.cxx
tests/unit/pixelformat.cxx
Commit message: Handle pixel formats with odd shift values

Our fast paths assume that each channel fits in to a separate byte.
That means the shift needs to be a multiple of 8. Start actually
checking this so that a client cannot trip us up and possibly cause
incorrect code exection.

Issue found by Pavel Cheremushkin from Kaspersky Lab.


Vulnerable code:

Fixed code:
  if ((redShift & 0x7) != 0)
    return false;
  if ((greenShift & 0x7) != 0)
    return false;
  if ((blueShift & 0x7) != 0)
    return false;
    /* Odd shifts */

    do888Test(false, 32, 24, false, true, 255, 255, 255, 0, 8, 18);
    do888Test(false, 32, 24, false, true, 255, 255, 255, 0, 11, 24);
    do888Test(false, 32, 24, false, true, 255, 255, 255, 4, 16, 24);
CVE-2024-6387 (Other, published 2024-07-01T13:15Z)
Description: value: A security regression (CVE-2006-5051) was discovered in OpenSSH's server (sshd). There is a race condition which can lead sshd to handle some signals in an unsafe manner. An unauthenticated, remote attacker may be able to trigger it by failing to authenticate within a set time period.
Severity: nan (CVSS v3 base score: 8.1)
Weakness: CWE-362 \u2014 Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
The product contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently.
Repository: https://github.com/openela-main/openssh
Files changed:
.openssh.metadata
SOURCES/openssh-9.8p1-upstream-cve-2024-6387.patch
SPECS/openssh.spec
Commit message: import openssh-8.7p1-38.el9_4.1

Vulnerable code:
9d440de6627940c09eadc342cc7d8bc9823654fd1a2be11c4f5820dd073054e0 SOURCES/pam_ssh_agent_auth-0.10.4.tar.gz
Release: %{openssh_rel}%{?dist}
Release: %{pam_ssh_agent_rel}.%{openssh_rel}%{?dist}

Fixed code:
9d440de6627940c09eadc342cc7d8bc9823654fd1a2be11c4f5820dd073054e0 SOURCES/pam_ssh_agent_auth-0.10.4.tar.gz
diff -up openssh-8.7p1/log.c.xxx openssh-8.7p1/log.c
--- openssh-8.7p1/log.c.xxx	2024-06-28 11:02:43.949912398 +0200
@@ -455,12 +455,14 @@ void
 sshsigdie(const char *file, const char *func, int line, int showfunc,
     LogLevel level, const char *suffix, const char *fmt, ...)
 {
+#if 0
 	va_list args;
 
 	va_start(args, fmt);
 	sshlogv(file, func, line, showfunc, SYSLOG_LEVEL_FATAL,
 	    suffix, fmt, args);
 	va_end(args);
+#endif
 	_exit(1);
 }
 
Release: %{openssh_rel}%{?dist}.1
Patch1020: openssh-9.8p1-upstream-cve-2024-6387.patch
Release: %{pam_ssh_agent_rel}.%{openssh_rel}%{?dist}.1
%patch1020 -p1 -b .cve-2024-6387
* Fri Jun 28 2024 Dmitry Belyavskiy <dbelyavs@redhat.com> - 8.7p1-38.1
- Possible remote code execution due to a race condition (CVE-2024-6387)
  Resolves: RHEL-45347
CVE-2024-6409 (Other, published 2024-07-08T18:15Z)
Description: value: A race condition vulnerability was discovered in how signals are handled by OpenSSH's server (sshd). If a remote attacker does not authenticate within a set time period, then sshd's SIGALRM handler is called asynchronously. However, this signal handler calls various functions that are not async-signal-safe, for example, syslog(). As a consequence of a successful attack, in the worst case scenario, an attacker may be able to perform a remote code execution (RCE) as an unprivileged user running the sshd server.
Severity: nan (CVSS v3 base score: )
Weakness: CWE-364 \u2014 Signal Handler Race Condition
The product uses a signal handler that introduces a race condition.
Repository: https://github.com/openela-main/openssh
Files changed:
.openssh.metadata
SOURCES/openssh-9.8p1-upstream-cve-2024-6387.patch
SPECS/openssh.spec
Commit message: import openssh-8.7p1-38.el9_4.4

Vulnerable code:
9d440de6627940c09eadc342cc7d8bc9823654fd1a2be11c4f5820dd073054e0 SOURCES/pam_ssh_agent_auth-0.10.4.tar.gz
Release: %{openssh_rel}%{?dist}.1
Release: %{pam_ssh_agent_rel}.%{openssh_rel}%{?dist}.1

Fixed code:
9d440de6627940c09eadc342cc7d8bc9823654fd1a2be11c4f5820dd073054e0 SOURCES/pam_ssh_agent_auth-0.10.4.tar.gz
diff -up openssh-8.7p1/sshd.c.xxx openssh-8.7p1/sshd.c
--- openssh-8.7p1/sshd.c.xxx	2024-07-01 10:33:04.332907749 +0200
@@ -384,7 +384,7 @@ grace_alarm_handler(int sig)
 
 	/* Log error and exit. */
 	if (use_privsep && pmonitor != NULL && pmonitor->m_pid <= 0)
-		cleanup_exit(255); /* don't log in privsep child */
+		_exit(255); /* don't log in privsep child */
 	else {
 		sigdie("Timeout before authentication for %s port %d",
 		    ssh_remote_ipaddr(the_active_state),
Release: %{openssh_rel}%{?dist}.4
Release: %{pam_ssh_agent_rel}.%{openssh_rel}%{?dist}.4
* Wed Jul 03 2024 Dmitry Belyavskiy <dbelyavs@redhat.com> - 8.7p1-38.4
- rebuilt

* Wed Jul 03 2024 Dmitry Belyavskiy <dbelyavs@redhat.com> - 8.7p1-38.3
- rebuilt

* Mon Jul 01 2024 Dmitry Belyavskiy <dbelyavs@redhat.com> - 8.7p1-38.2
- Possible remote code execution due to a race condition (CVE-2024-6409)
  Resolves: RHEL-45740
CVE-2024-21623 (YAML, published 2024-01-02T21:15Z)
Description: value: OTCLient is an alternative tibia client for otserv. Prior to commit db560de0b56476c87a2f967466407939196dd254, the /mehah/otclient "`Analysis - SonarCloud`" workflow is vulnerable to an expression injection in Actions, allowing an attacker to run commands remotely on the runner, leak secrets, and alter the repository using this workflow. Commit db560de0b56476c87a2f967466407939196dd254 contains a fix for this issue.
Severity: nan (CVSS v3 base score: 9.8)
Weakness: CWE-74 \u2014 Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
The product constructs all or part of a command, data structure, or record using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify how it is parsed or interpreted when it is sent to a downstream component.
Repository: https://github.com/mehah/otclient
Files changed:
.github/workflows/analysis-sonarcloud.yml
Commit message: Merge pull request from GHSA-q6gr-wc79-v589



Vulnerable code:
            --define sonar.pullrequest.branch=${{ github.event.pull_request.head.ref }} \

Fixed code:
          BRANCH: ${{ github.event.pull_request.head.ref }}
            --define sonar.pullrequest.branch=$BRANCH \
CVE-2017-1000008 (Other, published 2017-07-17T13:18Z)
Description: value: Chyrp Lite version 2016.04 is vulnerable to a CSRF in the user settings function allowing attackers to hijack the authentication of logged in users to modify account information, including their password.
Severity: MEDIUM (CVSS v3 base score: 8.8)
Weakness: CWE-352 \u2014 Cross-Site Request Forgery (CSRF)
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.
Repository: https://github.com/xenocrat/chyrp-lite
Files changed:
includes/controller/Main.php
themes/blossom/forms/user/controls.twig
themes/sparrow/forms/user/controls.twig
themes/topaz/forms/user/controls.twig
themes/umbra/forms/user/controls.twig
Commit message: MainController, Blog Themes: protect against CSRF

My thanks to @fleetcaptain for the report.


Vulnerable code:

Fixed code:
                if (!isset($_POST['hash']) or $_POST['hash'] != token($_SERVER["REMOTE_ADDR"]))
                    Flash::warning(__("Invalid security key."));

<input type="hidden" name="hash" value="{{ ip | token }}" id="hash">
<input type="hidden" name="hash" value="{{ ip | token }}" id="hash">
<input type="hidden" name="hash" value="{{ ip | token }}" id="hash">
<input type="hidden" name="hash" value="{{ ip | token }}" id="hash">
CVE-2013-0158 (Java, published 2013-02-24T22:55Z)
Description: value: Unspecified vulnerability in Jenkins before 1.498, Jenkins LTS before 1.480.2, and Jenkins Enterprise 1.447.x before 1.447.6.1 and 1.466.x before 1.466.12.1, when a slave is attached and anonymous read access is enabled, allows remote attackers to obtain the master cryptographic key via unknown vectors.
Severity: LOW (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/jenkinsci/jenkins
Files changed:
core/src/main/java/jenkins/security/ApiTokenProperty.java
test/src/test/java/jenkins/security/ApiTokenPropertyTest.java
Commit message: [SECURITY-49] actively invalidate bad API tokens.

If the user still has the API token that's generated from secret.key,
don't accept that.

Hopefully this is the last fix


Vulnerable code:
    private ApiTokenProperty(String seed) {
        return Util.getDigestOf(apiToken.getPlainText());

Fixed code:
import jenkins.model.Jenkins;
    /*package*/ ApiTokenProperty(String seed) {
        String p = apiToken.getPlainText();
        if (p.equals(Util.getDigestOf(Jenkins.getInstance().getSecretKey()+":"+user.getId()))) {
            // if the current token is the initial value created by pre SECURITY-49 Jenkins, we can't use that.
            // force using the newer value
            apiToken = Secret.fromString(p=API_KEY_SEED.mac(user.getId()));
        }
        return Util.getDigestOf(p);
import hudson.Util;
import jenkins.model.Jenkins;

    public void testSecurity49Upgrade() throws Exception {
        jenkins.setSecurityRealm(createDummySecurityRealm());
        User u = User.get("foo");
        String historicalInitialValue = Util.getDigestOf(Jenkins.getInstance().getSecretKey() + ":" + u.getId());

        // we won't accept historically used initial value as it may be compromised
        ApiTokenProperty t = new ApiTokenProperty(historicalInitialValue);
        u.addProperty(t);
        String apiToken1 = t.getApiToken();
        assertFalse(apiToken1.equals(Util.getDigestOf(historicalInitialValue)));

        // the replacement for the compromised value must be consistent and cannot be random
        ApiTokenProperty t2 = new ApiTokenProperty(historicalInitialValue);
        u.addProperty(t2);
        assertEquals(apiToken1,t2.getApiToken());

        // any other value is OK. those are changed values
        t = new ApiTokenProperty(historicalInitialValue+"somethingElse");
        u.addProperty(t);
        assertTrue(t.getApiToken().equals(Util.getDigestOf(historicalInitialValue+"somethingElse")));

    }