hitoshura25/cvefixes huggingface dataset:
CVE-2020-36324 (Python, published 2021-04-21T20:15Z)
Description: value: Wikimedia Quarry analytics-quarry-web before 2020-12-15 allows Reflected XSS because app.py does not explicitly set the application/json content type.
Severity: MEDIUM (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/wikimedia/analytics-quarry-web
Files changed:
quarry/web/app.py
Commit message: SECURITY: Set correct Mime Type on /api/preferences

Prevents a Reflected Cross-Site scripting (XSS) vulnerability

Bug: T270195
Change-Id: I04bf53d2a939da369e54e91899615a3ffc3e5caf


Vulnerable code:
        return Response(json.dumps({'key': key, 'value': get_preferences()[key]}))
        return Response(json.dumps({'key': key, 'error': 'novalue'}))
    return Response(json.dumps({'key': key, 'success': ''})), 201

Fixed code:
        return Response(
            json.dumps({'key': key, 'value': get_preferences()[key]}),
            mimetype='application/json'
        )
        return Response(
            json.dumps({'key': key, 'error': 'novalue'}),
            mimetype='application/json'
        )
    return Response(
        json.dumps({'key': key, 'success': ''}),
        mimetype='application/json'
    ), 201
CVE-2014-125082 (Python, published 2023-01-18T00:15Z)
Description: value: A vulnerability was found in nivit redports. It has been declared as critical. This vulnerability affects unknown code of the file redports-trac/redports/model.py. The manipulation leads to sql injection. The name of the patch is fc2c1ea1b8d795094abb15ac73cab90830534e04. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-218464.
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/nivit/redports
Files changed:
redports-trac/redports/model.py
Commit message: redports-trac:
- Fix a possible SQL injection


Vulnerable code:
	self.revision = int(revision)
            filter += "AND buildqueue.id = '%s'" % (self.queueid)
            filter += "AND buildqueue.owner = '%s'" % (self.owner)
            filter += "AND buildqueue.revision = '%s'" % (self.revision)

Fixed code:
	self.revision = revision
            filter += "AND buildqueue.id = '%s'" % (re.sub("[\"']", "", self.queueid))
            filter += "AND buildqueue.owner = '%s'" % (re.sub("[\"']", "", self.owner))
            filter += "AND buildqueue.revision = %s" % (int(self.revision))
CVE-2023-28109 (Go, published 2023-03-16T17:15Z)
Description: value: Play With Docker is a browser-based Docker playground. Versions 0.0.2 and prior are vulnerable to domain hijacking.
Because CORS configuration was not correct, an attacker could use `play-with-docker.com` as an example and set the origin header in an http request as `evil-play-with-docker.com`. The domain would echo in response header, which successfully bypassed the CORS policy and retrieved basic user information. This issue has been fixed in commit ed82247c9ab7990ad76ec2bf1498c2b2830b6f1a. There are no known workarounds.
Severity: nan (CVSS v3 base score: 6.5)
Weakness: CWE-639 \u2014 Authorization Bypass Through User-Controlled Key
The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.
Repository: https://github.com/play-with-docker/play-with-docker
Files changed:
handlers/bootstrap.go
Commit message: fix CORS origins to avoid domain hijacking

Signed-off-by: Marcos Lilljedahl <marcosnils@gmail.com>


Vulnerable code:
			strings.HasSuffix(origin, "play-with-docker.com") ||
			strings.HasSuffix(origin, "play-with-kubernetes.com") ||
			strings.HasSuffix(origin, "docker.com") ||
			strings.HasSuffix(origin, "play-with-go.dev") {

Fixed code:
			strings.HasSuffix(origin, ".play-with-docker.com") ||
			strings.HasSuffix(origin, ".play-with-kubernetes.com") ||
			strings.HasSuffix(origin, ".docker.com") ||
			strings.HasSuffix(origin, ".play-with-go.dev") {
CVE-2018-20748 (C, published 2019-01-30T18:29Z)
Description: value: LibVNC before 0.9.12 contains multiple heap out-of-bounds write vulnerabilities in libvncclient/rfbproto.c. The fix for CVE-2018-20019 was incomplete.
Severity: HIGH (CVSS v3 base score: 9.8)
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/LibVNC/libvncserver
Files changed:
libvncclient/rfbproto.c
Commit message: LibVNCClient: ignore server-sent reason strings longer than 1MB

Fixes #273


Vulnerable code:
    uint32_t authResult=0, reasonLen=0;
    char *reason=NULL;
        if (!ReadFromRFBServer(client, (char *)&reasonLen, 4)) return FALSE;
        reasonLen = rfbClientSwap32IfLE(reasonLen);
        reason = malloc((uint64_t)reasonLen+1);
        if (!ReadFromRFBServer(client, reason, reasonLen)) { free(reason); return FALSE; }
        reason[reasonLen]=0;
        rfbClientLog("VNC connection failed: %s\n",reason);
        free(reason);
static void
ReadReason(rfbClient* client)
{
    uint32_t reasonLen;
    char *reason;

    /* we have an error following */
    if (!ReadFromRFBServer(client, (char *)&reasonLen, 4)) return;
    reasonLen = rfbClientSwap32IfLE(reasonLen);
    reason = malloc((uint64_t)reasonLen+1);
    if (!ReadFromRFBServer(client, reason, reasonLen)) { free(reason); return; }
    reason[reasonLen]=0;
    rfbClientLog("VNC connection failed: %s\n",reason);
    free(reason);
}

Fixed code:
static void
ReadReason(rfbClient* client)
{
    uint32_t reasonLen;
    char *reason;

    if (!ReadFromRFBServer(client, (char *)&reasonLen, 4)) return;
    reasonLen = rfbClientSwap32IfLE(reasonLen);
    if(reasonLen > 1<<20) {
      rfbClientLog("VNC connection failed, but sent reason length of %u exceeds limit of 1MB",(unsigned int)reasonLen);
      return;
    }
    reason = malloc(reasonLen+1);
    if (!ReadFromRFBServer(client, reason, reasonLen)) { free(reason); return; }
    reason[reasonLen]=0;
    rfbClientLog("VNC connection failed: %s\n",reason);
    free(reason);
}

    uint32_t authResult=0;
        ReadReason(client);
CVE-2018-20748 (C, published 2019-01-30T18:29Z)
Description: value: LibVNC before 0.9.12 contains multiple heap out-of-bounds write vulnerabilities in libvncclient/rfbproto.c. The fix for CVE-2018-20019 was incomplete.
Severity: HIGH (CVSS v3 base score: 9.8)
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/LibVNC/libvncserver
Files changed:
libvncclient/rfbproto.c
Commit message: LibVNCClient: ignore server-sent cut text longer than 1MB

This is in line with how LibVNCServer does it
(28afb6c537dc82ba04d5f245b15ca7205c6dbb9c) and fixes part of #273.


Vulnerable code:

Fixed code:
    if (msg.sct.length > 1<<20) {
	    rfbClientErr("Ignoring too big cut text length sent by server: %u B > 1 MB\n", (unsigned int)msg.sct.length);
	    return FALSE;
    }
CVE-2018-20748 (C, published 2019-01-30T18:29Z)
Description: value: LibVNC before 0.9.12 contains multiple heap out-of-bounds write vulnerabilities in libvncclient/rfbproto.c. The fix for CVE-2018-20019 was incomplete.
Severity: HIGH (CVSS v3 base score: 9.8)
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/LibVNC/libvncserver
Files changed:
libvncclient/rfbproto.c
Commit message: LibVNCClient: fail on server-sent desktop name lengths longer than 1MB

re #273


Vulnerable code:
  /* To guard against integer wrap-around, si.nameLength is cast to 64 bit */
  client->desktopName = malloc((uint64_t)client->si.nameLength + 1);

Fixed code:
  if (client->si.nameLength > 1<<20) {
      rfbClientErr("Too big desktop name length sent by server: %u B > 1 MB\n", (unsigned int)client->si.nameLength);
      return FALSE;
  }

  client->desktopName = malloc(client->si.nameLength + 1);
CVE-2018-20748 (C, published 2019-01-30T18:29Z)
Description: value: LibVNC before 0.9.12 contains multiple heap out-of-bounds write vulnerabilities in libvncclient/rfbproto.c. The fix for CVE-2018-20019 was incomplete.
Severity: HIGH (CVSS v3 base score: 9.8)
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/LibVNC/libvncserver
Files changed:
libvncclient/rfbproto.c
Commit message: LibVNCClient: remove now-useless cast

re #273


Vulnerable code:
    buffer = malloc((uint64_t)msg.sct.length+1);

Fixed code:
    buffer = malloc(msg.sct.length+1);
CVE-2018-20749 (C, published 2019-01-30T18:29Z)
Description: value: LibVNC before 0.9.12 contains a heap out-of-bounds write vulnerability in libvncserver/rfbserver.c. The fix for CVE-2018-15127 was incomplete.
Severity: HIGH (CVSS v3 base score: 9.8)
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/LibVNC/libvncserver
Files changed:
libvncserver/rfbserver.c
Commit message: Error out in rfbProcessFileTransferReadBuffer if length can not be allocated

re #273


Vulnerable code:
    rfbLog("rfbProcessFileTransferReadBuffer(%dlen)\n", length);
        buffer=malloc((uint64_t)length+1);

Fixed code:

       We later alloc length+1, which might wrap around on 32-bit systems if length equals
       0XFFFFFFFF, i.e. SIZE_MAX for 32-bit systems. On 64-bit systems, a length of 0XFFFFFFFF
       will safely be allocated since this check will never trigger and malloc() can digest length+1
       without problems as length is a uint32_t.
    if(length == SIZE_MAX) {
	rfbErr("rfbProcessFileTransferReadBuffer: too big file transfer length requested: %u", (unsigned int)length);
	rfbCloseClient(cl);
	return NULL;
    }

        buffer=malloc((size_t)length+1);
CVE-2018-20750 (C, published 2019-01-30T18:29Z)
Description: value: LibVNC through 0.9.12 contains a heap out-of-bounds write vulnerability in libvncserver/rfbserver.c. The fix for CVE-2018-15127 was incomplete.
Severity: HIGH (CVSS v3 base score: 9.8)
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/LibVNC/libvncserver
Files changed:
libvncserver/rfbserver.c
Commit message: Limit lenght to INT_MAX bytes in rfbProcessFileTransferReadBuffer()

This ammends 15bb719c03cc70f14c36a843dcb16ed69b405707 fix for a heap
out-of-bound write access in rfbProcessFileTransferReadBuffer() when
reading a transfered file content in a server. The former fix did not
work on platforms with a 32-bit int type (expected by rfbReadExact()).

CVE-2018-15127
<https://github.com/LibVNC/libvncserver/issues/243>
<https://github.com/LibVNC/libvncserver/issues/273>


Vulnerable code:
    if(length == SIZE_MAX) {

Fixed code:
/* INT_MAX */
#include <limits.h>
       We also later pass length to rfbReadExact() that expects a signed int type and
       that might wrap on platforms with a 32-bit int type if length is bigger
       than 0X7FFFFFFF.
    if(length == SIZE_MAX || length > INT_MAX) {
CVE-2019-15681 (C, published 2019-10-29T19:15Z)
Description: value: LibVNC commit before d01e1bb4246323ba6fcee3b82ef1faa9b1dac82a contains a memory leak (CWE-655) in VNC server code, which allow an attacker to read stack memory and can be abused for information disclosure. Combined with another vulnerability, it can be used to leak stack memory and bypass ASLR. This attack appear to be exploitable via network connectivity. These vulnerabilities have been fixed in commit d01e1bb4246323ba6fcee3b82ef1faa9b1dac82a.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-665 \u2014 Improper Initialization
The product does not initialize or incorrectly initializes a resource, which might leave the resource in an unexpected state when it is accessed or used.
Repository: https://github.com/LibVNC/libvncserver
Files changed:
libvncserver/rfbserver.c
Commit message: rfbserver: don't leak stack memory to the remote

Thanks go to Pavel Cheremushkin of Kaspersky for reporting.


Vulnerable code:

Fixed code:
    memset((char *)&sct, 0, sizeof(sct));
CVE-2019-20788 (C, published 2020-04-23T19:15Z)
Description: value: libvncclient/cursor.c in LibVNCServer through 0.9.12 has a HandleCursorShape integer overflow and heap-based buffer overflow via a large height or width value. NOTE: this may overlap CVE-2019-15690.
Severity: HIGH (CVSS v3 base score: 9.8)
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/LibVNC/libvncserver
Files changed:
libvncclient/cursor.c
Commit message: libvncclient/cursor: limit width/height input values

Avoids a possible heap overflow reported by Pavel Cheremushkin
<Pavel.Cheremushkin@kaspersky.com>.

re #275


Vulnerable code:

Fixed code:
#define MAX_CURSOR_SIZE 1024

  if (width >= MAX_CURSOR_SIZE || height >= MAX_CURSOR_SIZE)
    return FALSE;
CVE-2019-20788 (C, published 2020-04-23T19:15Z)
Description: value: libvncclient/cursor.c in LibVNCServer through 0.9.12 has a HandleCursorShape integer overflow and heap-based buffer overflow via a large height or width value. NOTE: this may overlap CVE-2019-15690.
Severity: HIGH (CVSS v3 base score: 9.8)
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/LibVNC/libvncserver
Files changed:
libvncclient/cursor.c
Commit message: libvncclient/cursor: limit width/height input values

Avoids a possible heap overflow reported by Pavel Cheremushkin
<Pavel.Cheremushkin@kaspersky.com>.

re #275


Vulnerable code:

Fixed code:
#define MAX_CURSOR_SIZE 1024

  if (width >= MAX_CURSOR_SIZE || height >= MAX_CURSOR_SIZE)
    return FALSE;
CVE-2019-20839 (C, published 2020-06-17T16:15Z)
Description: value: libvncclient/sockets.c in LibVNCServer before 0.9.13 has a buffer overflow via a long socket filename.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-120 \u2014 Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
The product copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow.
Repository: https://github.com/LibVNC/libvncserver
Files changed:
libvncclient/sockets.c
Commit message: libvncclient: bail out if unix socket name would overflow

Closes #291


Vulnerable code:

Fixed code:
  if(strlen(sockFile) + 1 > sizeof(addr.sun_path)) {
      rfbClientErr("ConnectToUnixSock: socket file name too long\n");
      return -1;
  }
CVE-2019-20840 (C, published 2020-06-17T16:15Z)
Description: value: An issue was discovered in LibVNCServer before 0.9.13. libvncserver/ws_decode.c can lead to a crash because of unaligned accesses in hybiReadAndDecode.
Severity: MEDIUM (CVSS v3 base score: 7.5)
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/LibVNC/libvncserver
Files changed:
libvncserver/ws_decode.c
Commit message: fix crash because of unaligned accesses in hybiReadAndDecode()


Vulnerable code:
  uint32_t *data32;
  data32= (uint32_t *)data;
    data32[i] ^= wsctx->header.mask.u;

Fixed code:
    uint32_t tmp;
    memcpy(&tmp, data + i * sizeof(tmp), sizeof(tmp));
    tmp ^= wsctx->header.mask.u;
    memcpy(data + i * sizeof(tmp), &tmp, sizeof(tmp));
CVE-2020-14396 (C, published 2020-06-17T16:15Z)
Description: value: An issue was discovered in LibVNCServer before 0.9.13. libvncclient/tls_openssl.c has a NULL pointer dereference.
Severity: MEDIUM (CVSS v3 base score: 7.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/LibVNC/libvncserver
Files changed:
libvncclient/tls_openssl.c
Commit message: libvncclient/tls_openssl: do not deref a NULL pointer

Happens in anonTLS mode where cred is NULL.

re #347


Vulnerable code:
  uint8_t verify_crls = cred->x509Credential.x509CrlVerifyMode;

Fixed code:
  uint8_t verify_crls;
    verify_crls = cred->x509Credential.x509CrlVerifyMode;
CVE-2020-14397 (C, published 2020-06-17T16:15Z)
Description: value: An issue was discovered in LibVNCServer before 0.9.13. libvncserver/rfbregion.c has a NULL pointer dereference.
Severity: MEDIUM (CVSS v3 base score: 7.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/LibVNC/libvncserver
Files changed:
libvncserver/rfbregion.c
libvncserver/rfbserver.c
Commit message: libvncserver: add missing NULL pointer checks


Vulnerable code:
  newspan->_next = after->_next;
  newspan->_prev = after;
  after->_next->_prev = newspan;
  after->_next = newspan;
  newspan->_next = before;
  newspan->_prev = before->_prev;
  before->_prev->_next = newspan;
  before->_prev = newspan;
  span->_prev->_next = span->_next;
  span->_next->_prev = span->_prev;
  if(iterator->next) rfbDecrClientRef(iterator->next);

Fixed code:
  if(newspan && after) {
    newspan->_next = after->_next;
    newspan->_prev = after;
    after->_next->_prev = newspan;
    after->_next = newspan;
  }
  if(newspan && before) {
    newspan->_next = before;
    newspan->_prev = before->_prev;
    before->_prev->_next = newspan;
    before->_prev = newspan;
  }
  if(span) {
    span->_prev->_next = span->_next;
    span->_next->_prev = span->_prev;
  }
  if (!i)
    return NULL;
  if(iterator && iterator->next) rfbDecrClientRef(iterator->next);
CVE-2020-14398 (C, published 2020-06-17T16:15Z)
Description: value: An issue was discovered in LibVNCServer before 0.9.13. An improperly closed TCP connection causes an infinite loop in libvncclient/sockets.c.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-835 \u2014 Loop with Unreachable Exit Condition ('Infinite Loop')
The product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop.
Repository: https://github.com/LibVNC/libvncserver
Files changed:
libvncclient/sockets.c
libvncclient/vncviewer.c
rfb/rfbclient.h
Commit message: libvncclient: handle half-open TCP connections

When a connection is not reset properly at the TCP level (e.g. sudden
power loss or process crash) the TCP connection becomes half-open and
read() always returns -1 with errno = EAGAIN while select() always
returns 0. This leads to an infinite loop and can be fixed by closing
the connection after a certain number of retries (based on a timeout)
has been exceeded.


Vulnerable code:
	    WaitForMessage(client, 100000);
	    WaitForMessage(client, 100000);

Fixed code:
  const int USECS_WAIT_PER_RETRY = 100000;
  int retries = 0;
	    if (client->readTimeout > 0 &&
		++retries > (client->readTimeout * 1000 * 1000 / USECS_WAIT_PER_RETRY))
	    {
	      rfbClientLog("Connection timed out\n");
	      return FALSE;
	    }
	    WaitForMessage(client, USECS_WAIT_PER_RETRY);
	    if (client->readTimeout > 0 &&
		++retries > (client->readTimeout * 1000 * 1000 / USECS_WAIT_PER_RETRY))
	    {
		rfbClientLog("Connection timed out\n");
		return FALSE;
	    }
	    WaitForMessage(client, USECS_WAIT_PER_RETRY);
  client->readTimeout = DEFAULT_READ_TIMEOUT;
#define DEFAULT_READ_TIMEOUT 0
	/* timeout in seconds when reading from half-open connections in
	 * ReadFromRFBServer() - keep at 0 to disable timeout detection and handling */
	unsigned int readTimeout;
CVE-2020-14399 (C, published 2020-06-17T16:15Z)
Description: value: An issue was discovered in LibVNCServer before 0.9.13. Byte-aligned data is accessed through uint32_t pointers in libvncclient/rfbproto.c. NOTE: there is reportedly "no trust boundary crossed.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: NVD-CWE-Other \u2014 Other
NVD is only using a subset of CWE for mapping instead of the entire CWE, and the weakness type is not covered by that subset.
Repository: https://github.com/LibVNC/libvncserver
Files changed:
libvncclient/rfbproto.c
Commit message: libvncclient: fix pointer aliasing/alignment issue

Accessing byte-aligned data through uint32_t pointers can cause crashes
on some platforms or reduce the performance. Therefore ensure a proper
stack alignment.


Vulnerable code:
  char buf[sz_rfbSetEncodingsMsg + MAX_ENCODINGS * 4];
  rfbSetEncodingsMsg *se = (rfbSetEncodingsMsg *)buf;
  uint32_t *encs = (uint32_t *)(&buf[sz_rfbSetEncodingsMsg]);
  if (!WriteToRFBServer(client, buf, len)) return FALSE;

Fixed code:
  union {
    char bytes[sz_rfbSetEncodingsMsg + MAX_ENCODINGS*4];
    rfbSetEncodingsMsg msg;
  } buf;
  rfbSetEncodingsMsg *se = &buf.msg;
  uint32_t *encs = (uint32_t *)(&buf.bytes[sz_rfbSetEncodingsMsg]);
  if (!WriteToRFBServer(client, buf.bytes, len)) return FALSE;
CVE-2020-14400 (C, published 2020-06-17T16:15Z)
Description: value: An issue was discovered in LibVNCServer before 0.9.13. Byte-aligned data is accessed through uint16_t pointers in libvncserver/translate.c. NOTE: Third parties do not consider this to be a vulnerability as there is no known path of exploitation or cross of a trust boundary
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: NVD-CWE-Other \u2014 Other
NVD is only using a subset of CWE for mapping instead of the entire CWE, and the weakness type is not covered by that subset.
Repository: https://github.com/LibVNC/libvncserver
Files changed:
libvncserver/translate.c
Commit message: libvncserver: fix pointer aliasing/alignment issue

Accessing byte-aligned data through uint16_t pointers can cause crashes
on some platforms or reduce the performance. Therefore ensure a proper
stack alignment.


Vulnerable code:
    char buf[sz_rfbSetColourMapEntriesMsg + 256 * 3 * 2];
    rfbSetColourMapEntriesMsg *scme = (rfbSetColourMapEntriesMsg *)buf;
    uint16_t *rgb = (uint16_t *)(&buf[sz_rfbSetColourMapEntriesMsg]);
    if (rfbWriteExact(cl, buf, len) < 0) {

Fixed code:
    union {
        char bytes[sz_rfbSetColourMapEntriesMsg + 256 * 3 * 2];
        rfbSetColourMapEntriesMsg msg;
    } buf;
    rfbSetColourMapEntriesMsg *scme = &buf.msg;
    uint16_t *rgb = (uint16_t *)(&buf.bytes[sz_rfbSetColourMapEntriesMsg]);
    if (rfbWriteExact(cl, buf.bytes, len) < 0) {