Publicus/cvefixes-security-ir-graphrag huggingface dataset:
CVE-2020-12268: Out-of-bounds Write (CWE-787)
value: jbig2_image_compose in jbig2_image.c in Artifex jbig2dec before 0.18 has a heap-based buffer overflow.
CWE description: The product writes data past the end, or before the beginning, of the intended buffer.
CVSS v3 base score: 9.8
Published: 2020-04-27T02:15Z
Repository: https://github.com/ArtifexSoftware/jbig2dec
Language: C
Files changed: jbig2_image.c
Commit date: 2020-01-27 18:26:13 +0000
Commit message: Fix OSS-Fuzz issue 20332: buffer overflow in jbig2_image_compose.

With extreme values of x/y/w/h we can get overflow. Test for this
and exit safely.

Thanks for OSS-Fuzz for reporting.

Diff: diff --git a/jbig2_image.c b/jbig2_image.c
index bb4b0e3..70c985a 100644
--- a/jbig2_image.c
+++ b/jbig2_image.c
@@ -31,10 +31,13 @@
 #include "jbig2_image.h"
 
 #if !defined (INT32_MAX)
 #define INT32_MAX  0x7fffffff
 #endif
+#if !defined (UINT32_MAX)
+#define UINT32_MAX  0xffffffffu
+#endif
 
 /* allocate a Jbig2Image structure and its associated bitmap */
 Jbig2Image *
 jbig2_image_new(Jbig2Ctx *ctx, uint32_t width, uint32_t height)
 {
@@ -349,10 +352,19 @@ jbig2_image_compose(Jbig2Ctx *ctx, Jbig2Image *dst, Jbig2Image *src, int x, int
     uint32_t syoffset = 0;
 
     if (src == NULL)
         return 0;
 
+    if ((UINT32_MAX - src->width  < (x > 0 ? x : -x)) ||
+        (UINT32_MAX - src->height < (y > 0 ? y : -y)))
+    {
+#ifdef JBIG2_DEBUG
+        jbig2_error(ctx, JBIG2_SEVERITY_DEBUG, -1, "overflow in compose_image");
+#endif
+        return 0;
+    }
+
     /* This code takes a src image and combines it onto dst at offset (x,y), with operation op. */
 
     /* Data is packed msb first within a byte, so with bits numbered: 01234567.
      * Second byte is: 89abcdef. So to combine into a run, we use:
      *       (s[0]<<8) | s[1] == 0123456789abcdef.

Fixed code: #if !defined (UINT32_MAX)
#define UINT32_MAX  0xffffffffu
#endif
    if ((UINT32_MAX - src->width  < (x > 0 ? x : -x)) ||
        (UINT32_MAX - src->height < (y > 0 ? y : -y)))
    {
#ifdef JBIG2_DEBUG
        jbig2_error(ctx, JBIG2_SEVERITY_DEBUG, -1, "overflow in compose_image");
#endif
        return 0;
    }
CVE-2010-2060: Other (NVD-CWE-Other)
value: The put command functionality in beanstalkd 1.4.5 and earlier allows remote attackers to execute arbitrary Beanstalk commands via the body in a job that is too big, which is not properly handled by the dispatch_cmd function in prot.c.
CWE description: 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.
Published: 2010-06-08T00:30Z
Repository: https://github.com/kr/beanstalkd
Language: Other
Files changed: check-one.sh, prot.c, sh-tests/too-big.commands, sh-tests/too-big.expected
Commit date: 2010-05-23 00:36:10 -0700
Commit message: Discard job body bytes if the job is too big.

Previously, a malicious user could craft a job payload and inject
beanstalk commands without the client application knowing. (An
extra-careful client library could check the size of the job body before
sending the put command, but most libraries do not do this, nor should
they have to.)

Reported by Graham Barr.

Diff: diff --git a/check-one.sh b/check-one.sh
index 709993f..bcfb7d4 100755
--- a/check-one.sh
+++ b/check-one.sh
@@ -32,11 +32,11 @@ trap catch HUP INT QUIT TERM
 if [ ! -x ./beanstalkd ]; then
   echo "Executable ./beanstalkd not found; do you need to compile first?"
   exit 2
 fi
 
-start_beanstalkd
+start_beanstalkd '' '-z 10'
 
 # Run the test
 fgrep -v "#" $commands | $nc $server $port > "$tmpf"
 
 # Check the output
diff --git a/prot.c b/prot.c
index 93fe8ce..481b0ed 100644
--- a/prot.c
+++ b/prot.c
@@ -1194,11 +1194,12 @@ dispatch_cmd(conn c)
         errno = 0;
         body_size = strtoul(size_buf, &end_buf, 10);
         if (errno) return reply_msg(c, MSG_BAD_FORMAT);
 
         if (body_size > job_data_size_limit) {
-            return reply_msg(c, MSG_JOB_TOO_BIG);
+            /* throw away the job body and respond with JOB_TOO_BIG */
+            return skip(c, body_size + 2, MSG_JOB_TOO_BIG);
         }
 
         /* don't allow trailing garbage */
         if (end_buf[0] != '\0') return reply_msg(c, MSG_BAD_FORMAT);
 
diff --git a/sh-tests/too-big.commands b/sh-tests/too-big.commands
new file mode 100644
index 0000000..d85cd39
--- /dev/null
+++ b/sh-tests/too-big.commands
@@ -0,0 +1,3 @@
+put 0 0 0 11
+delete 9999
+quit
diff --git a/sh-tests/too-big.expected b/sh-tests/too-big.expected
new file mode 100644
index 0000000..88448bc
--- /dev/null
+++ b/sh-tests/too-big.expected
@@ -0,0 +1 @@
+JOB_TOO_BIG

Vulnerable code: start_beanstalkd
            return reply_msg(c, MSG_JOB_TOO_BIG);
Fixed code: start_beanstalkd '' '-z 10'
            /* throw away the job body and respond with JOB_TOO_BIG */
            return skip(c, body_size + 2, MSG_JOB_TOO_BIG);
put 0 0 0 11
delete 9999
quit
JOB_TOO_BIG
CVE-2020-5235: Out-of-bounds Read (CWE-125)
value: There is a potentially exploitable out of memory condition In Nanopb before 0.4.1, 0.3.9.5, and 0.2.9.4. When nanopb is compiled with PB_ENABLE_MALLOC, the message to be decoded contains a repeated string, bytes or message field and realloc() runs out of memory when expanding the array nanopb can end up calling `free()` on a pointer value that comes from uninitialized memory. Depending on platform this can result in a crash or further memory corruption, which may be exploitable in some cases. This problem is fixed in nanopb-0.4.1, nanopb-0.3.9.5, nanopb-0.2.9.4.
CWE description: The product reads data past the end, or before the beginning, of the intended buffer.
CVSS v3 base score: 9.8
Published: 2020-02-04T03:15Z
Repository: https://github.com/nanopb/nanopb
Language: C
Files changed: pb_decode.c
Commit date: 2020-02-01 20:12:30 +0200
Commit message: Fix invalid free() after failed realloc() (GHSA-gcx3-7m76-287p)

Diff: diff --git a/pb_decode.c b/pb_decode.c
index 27c89c4..f16837b 100644
--- a/pb_decode.c
+++ b/pb_decode.c
@@ -718,15 +718,15 @@ static bool checkreturn decode_pointer_field(pb_istream_t *stream, pb_wire_type_
                     PB_RETURN_ERROR(stream, "too many array entries");
                 
                 if (!check_wire_type(wire_type, field))
                     PB_RETURN_ERROR(stream, "wrong wire type");
 
-                (*size)++;
-                if (!allocate_field(stream, field->pField, field->data_size, *size))
+                if (!allocate_field(stream, field->pField, field->data_size, (size_t)(*size + 1)))
                     return false;
             
-                field->pData = *(char**)field->pField + field->data_size * (*size - 1);
+                field->pData = *(char**)field->pField + field->data_size * (*size);
+                (*size)++;
                 initialize_pointer_field(field->pData, field);
                 return decode_basic_field(stream, field);
             }
 
         default:

Vulnerable code:                 (*size)++;
                if (!allocate_field(stream, field->pField, field->data_size, *size))
                field->pData = *(char**)field->pField + field->data_size * (*size - 1);
Fixed code:                 if (!allocate_field(stream, field->pField, field->data_size, (size_t)(*size + 1)))
                field->pData = *(char**)field->pField + field->data_size * (*size);
                (*size)++;
CVE-2021-21401: Release of Invalid Pointer or Reference (CWE-763)
value: Nanopb is a small code-size Protocol Buffers implementation in ansi C. In Nanopb before versions 0.3.9.8 and 0.4.5, decoding a specifically formed message can cause invalid `free()` or `realloc()` calls if the message type contains an `oneof` field, and the `oneof` directly contains both a pointer field and a non-pointer field. If the message data first contains the non-pointer field and then the pointer field, the data of the non-pointer field is incorrectly treated as if it was a pointer value. Such message data rarely occurs in normal messages, but it is a concern when untrusted data is parsed. This has been fixed in versions 0.3.9.8 and 0.4.5. See referenced GitHub Security Advisory for more information including workarounds.
CWE description: The product attempts to return a memory resource to the system, but it calls the wrong release function or calls the appropriate release function incorrectly.
CVSS v3 base score: 7.1
Published: 2021-03-23T18:15Z
Repository: https://github.com/nanopb/nanopb
Language: C
Files changed: pb_decode.c
Commit date: 2021-03-20 09:45:04 +0200
Commit message: Fix invalid free() with oneof (#647)

Nanopb would call free() or realloc() on an invalid
(attacker controlled) pointer value when all the following
conditions are true:

- PB_ENABLE_MALLOC is defined at the compile time
- Message definition contains an oneof field, and the oneof
  contains at least one pointer type field and at least one
  non-pointer type field.
- Data being decoded first contains a non-pointer value for
  the oneof field, and later contains an overwriting pointer
  value.

Depending on message layout, the bug may not be exploitable in all
cases, but it is known to be exploitable at least with string and
bytes fields. Actual security impact will also depend on the heap
implementation used.

Diff: diff --git a/pb_decode.c b/pb_decode.c
index 5f3b51e..b194825 100644
--- a/pb_decode.c
+++ b/pb_decode.c
@@ -1201,10 +1201,18 @@ static bool pb_release_union_field(pb_istream_t *stream, pb_field_iter_t *field)
     if (!pb_field_iter_find(&old_field, old_tag))
         PB_RETURN_ERROR(stream, "invalid union tag");
 
     pb_release_single_field(&old_field);
 
+    if (PB_ATYPE(field->type) == PB_ATYPE_POINTER)
+    {
+        /* Initialize the pointer to NULL to make sure it is valid
+         * even in case of error return. */
+        *(void**)field->pField = NULL;
+        field->pData = NULL;
+    }
+
     return true;
 }
 
 static void pb_release_single_field(pb_field_iter_t *field)
 {

Fixed code:     if (PB_ATYPE(field->type) == PB_ATYPE_POINTER)
    {
        /* Initialize the pointer to NULL to make sure it is valid
         * even in case of error return. */
        *(void**)field->pField = NULL;
        field->pData = NULL;
    }
CVE-2017-20168: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') (CWE-89)
value: A vulnerability was found in jfm-so piWallet. It has been rated as critical. Affected by this issue is some unknown functionality of the file api.php. The manipulation of the argument key leads to sql injection. The patch is identified as b420f8c4cbe7f06a34d1b05e90ee5cdfe0aa83bb. It is recommended to apply a patch to fix this issue. VDB-218006 is the identifier assigned to this vulnerability.
CWE description: 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.
CVSS v3 base score: 9.8
Published: 2023-01-11T15:15Z
Repository: https://github.com/jfm-so/piWallet
Language: PHP
Files changed: api.php
Commit date: 2017-03-26 19:34:26 +0100
Commit message: Fixed SQL Injection Issues
Diff: diff --git a/api.php b/api.php
index 013a526..8cc1ba5 100644
--- a/api.php
+++ b/api.php
@@ -3,11 +3,11 @@
 define("IN_WALLET", false); #TO ENABLE SET TO TRUE
 ###################################################
 
 include('common.php');
 $con = mysqli_connect("$db_host","$db_user","$db_pass","$db_name");
-$key = $_GET['key'];
+$key = mysqli_real_escape_string($con, $_GET['key']);
 if (mysqli_connect_errno()) {
     echo "Failed to connect to MySQL. Make sure to edit the common.php file: " . mysqli_connect_error();
 }
 $result = mysqli_query($con,"SELECT * FROM users where secret = '$key' and authused=1");
 

Vulnerable code: $key = $_GET['key'];
Fixed code: $key = mysqli_real_escape_string($con, $_GET['key']);
CVE-2015-10054: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') (CWE-89)
value: A vulnerability, which was classified as critical, was found in githuis P2Manage. This affects the function Execute of the file PTwoManage/Database.cs. The manipulation of the argument sql leads to sql injection. The identifier of the patch is 717380aba80002414f82d93c770035198b7858cc. It is recommended to apply a patch to fix this issue. The identifier VDB-218397 was assigned to this vulnerability.
CWE description: 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.
CVSS v3 base score: 9.8
Published: 2023-01-16T18:15Z
Repository: https://github.com/githuis/P2Manage
Language: C#
Files changed: PTwoManage/Database.cs
Commit date: 2015-05-15 23:01:13 +0200
Commit message: Little fix against sql injections

Diff: diff --git a/PTwoManage/Database.cs b/PTwoManage/Database.cs
index 67f5c25..c7d3b55 100644
--- a/PTwoManage/Database.cs
+++ b/PTwoManage/Database.cs
@@ -47,10 +47,15 @@ namespace PTwoManage
 
         }
 
         public void Execute(string sql)
         {
+            if(sql.Contains(";"))
+            {
+                System.Windows.Forms.MessageBox.Show("Cannot execute database request, please do not use semicolon ';' anywhere");
+                return;
+            }
             SQLiteCommand command = new SQLiteCommand(sql, m_dbConnection);
             command.ExecuteNonQuery();
         }
 
         public void Read(string sql, ref List<string> resultData, params string[] elements)

Fixed code:             if(sql.Contains(";"))
            {
                System.Windows.Forms.MessageBox.Show("Cannot execute database request, please do not use semicolon ';' anywhere");
                return;
            }
CVE-2016-10197: Out-of-bounds Read (CWE-125)
value: The search_make_new function in evdns.c in libevent before 2.1.6-beta allows attackers to cause a denial of service (out-of-bounds read) via an empty hostname.
CWE description: The product reads data past the end, or before the beginning, of the intended buffer.
CVSS v3 base score: 7.5
Published: 2017-03-15T15:59Z
Repository: https://github.com/libevent/libevent
Language: C
Files changed: evdns.c
Commit date: 2016-03-25 00:37:46 +0300
Commit message: evdns: fix searching empty hostnames

From #332:
  Here follows a bug report by **Guido Vranken** via the _Tor bug bounty program_. Please credit Guido accordingly.

  ## Bug report

  The DNS code of Libevent contains this rather obvious OOB read:

  ```c
  static char *
  search_make_new(const struct search_state *const state, int n, const char *const base_name) {
      const size_t base_len = strlen(base_name);
      const char need_to_append_dot = base_name[base_len - 1] == '.' ? 0 : 1;
  ```

  If the length of ```base_name``` is 0, then line 3125 reads 1 byte before the buffer. This will trigger a crash on ASAN-protected builds.

  To reproduce:

  Build libevent with ASAN:
  ```
  $ CFLAGS='-fomit-frame-pointer -fsanitize=address' ./configure && make -j4
  ```
  Put the attached ```resolv.conf``` and ```poc.c``` in the source directory and then do:

  ```
  $ gcc -fsanitize=address -fomit-frame-pointer poc.c .libs/libevent.a
  $ ./a.out
  =================================================================
  ==22201== ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60060000efdf at pc 0x4429da bp 0x7ffe1ed47300 sp 0x7ffe1ed472f8
  READ of size 1 at 0x60060000efdf thread T0
  ```

P.S. we can add a check earlier, but since this is very uncommon, I didn't add it.

Fixes: #332

Diff: diff --git a/evdns.c b/evdns.c
index 905ff6b5..e9dbc35c 100644
--- a/evdns.c
+++ b/evdns.c
@@ -3173,13 +3173,16 @@ search_set_from_hostname(struct evdns_base *base) {
 
 /* warning: returns malloced string */
 static char *
 search_make_new(const struct search_state *const state, int n, const char *const base_name) {
 	const size_t base_len = strlen(base_name);
-	const char need_to_append_dot = base_name[base_len - 1] == '.' ? 0 : 1;
+	char need_to_append_dot;
 	struct search_domain *dom;
 
+	if (!base_len) return NULL;
+	need_to_append_dot = base_name[base_len - 1] == '.' ? 0 : 1;
+
 	for (dom = state->head; dom; dom = dom->next) {
 		if (!n--) {
 			/* this is the postfix we want */
 			/* the actual postfix string is kept at the end of the structure */
 			const u8 *const postfix = ((u8 *) dom) + sizeof(struct search_domain);

Vulnerable code: 	const char need_to_append_dot = base_name[base_len - 1] == '.' ? 0 : 1;
Fixed code: 	char need_to_append_dot;
	if (!base_len) return NULL;
	need_to_append_dot = base_name[base_len - 1] == '.' ? 0 : 1;
CVE-2023-30847: Access of Uninitialized Pointer (CWE-824)
value: H2O is an HTTP server. In versions 2.3.0-beta2 and prior, when the reverse proxy handler tries to processes a certain type of invalid HTTP request, it tries to build an upstream URL by reading from uninitialized pointer. This behavior can lead to crashes or leak of information to back end HTTP servers. Pull request  number 3229 fixes the issue. The pull request has been merged to the `master` branch in commit f010336. Users should upgrade to commit f010336 or later.
CWE description: The product accesses or uses a pointer that has not been initialized.
CVSS v3 base score: 8.2
Published: 2023-04-27T15:15Z
Repository: https://github.com/h2o/h2o
Language: Unknown
Commit date: 2023-04-27 22:14:41 +0900
Commit message: Merge pull request #3229 from h2o/kazuho/reverse-proxy-invalid-read

[reverse proxy] invalid memory read
CVE-2023-41337: Improper Verification of Cryptographic Signature (CWE-347)
value: h2o is an HTTP server with support for HTTP/1.x, HTTP/2 and HTTP/3. In version 2.3.0-beta2 and prior, when h2o is configured to listen to multiple addresses or ports with each of them using different backend servers managed by multiple entities, a malicious backend entity that also has the opportunity to observe or inject packets exchanged between the client and h2o may misdirect HTTPS requests going to other backends and observe the contents of that HTTPS request being sent.

The attack involves a victim client trying to resume a TLS connection and an attacker redirecting the packets to a different address or port than that intended by the client. The attacker must already have been configured by the administrator of h2o to act as a backend to one of the addresses or ports that the h2o instance listens to. Session IDs and tickets generated by h2o are not bound to information specific to the server address, port, or the X.509 certificate, and therefore it is possible for an attacker to force the victim connection to wrongfully resume against a different server address or port on which the same h2o instance is listening.

Once a TLS session is misdirected to resume to a server address / port that is configured to use an attacker-controlled server as the backend, depending on the configuration, HTTPS requests from the victim client may be forwarded to the attacker's server.

An H2O instance is vulnerable to this attack only if the instance is configured to listen to different addresses or ports using the listen directive at the host level and the instance is configured to connect to backend servers managed by multiple entities.

A patch is available at commit 35760540337a47e5150da0f4a66a609fad2ef0ab. As a workaround, one may stop using using host-level listen directives in favor of global-level ones.
CWE description: The product does not verify, or incorrectly verifies, the cryptographic signature for data.
CVSS v3 base score: 6.7
Published: 2023-12-12T20:15Z
Repository: https://github.com/h2o/h2o
Language: Unknown
Commit date: 2023-12-12 21:31:47 +0900
Commit message: Merge pull request from GHSA-5v5r-rghf-rm6q

block cross-certificate session resumption
CVE-2023-50247: Allocation of Resources Without Limits or Throttling (CWE-770)
value: h2o is an HTTP server with support for HTTP/1.x, HTTP/2 and HTTP/3. The QUIC stack (quicly), as used by H2O up to commit 43f86e5 (in version 2.3.0-beta and prior), is susceptible to a state exhaustion attack. When H2O is serving HTTP/3, a remote attacker can exploit this vulnerability to progressively increase the memory retained by the QUIC stack. This can eventually cause H2O to abort due to memory exhaustion. The vulnerability has been resolved in commit d67e81d03be12a9d53dc8271af6530f40164cd35. HTTP/1 and HTTP/2 are not affected by this vulnerability as they do not use QUIC. Administrators looking to mitigate this issue without upgrading can disable HTTP/3 support.
CWE description: The product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor.
CVSS v3 base score: 7.5
Published: 2023-12-12T20:15Z
Repository: https://github.com/h2o/h2o
Language: Unknown
Commit date: 2023-12-12 22:03:08 +0900
Commit message: Merge pull request from GHSA-2ch5-p59c-7mv6

QUIC state exhaustion DoS
CVE-2024-2952: Improper Neutralization of Equivalent Special Elements (CWE-76)
value: BerriAI/litellm is vulnerable to Server-Side Template Injection (SSTI) via the `/completions` endpoint. The vulnerability arises from the `hf_chat_template` method processing the `chat_template` parameter from the `tokenizer_config.json` file through the Jinja template engine without proper sanitization. Attackers can exploit this by crafting malicious `tokenizer_config.json` files that execute arbitrary code on the server.
CWE description: The product correctly neutralizes certain special elements, but it improperly neutralizes equivalent special elements.
Published: 2024-04-10T17:15Z
Repository: https://github.com/berriai/litellm
Language: Unknown
Commit date: 2024-04-10 21:28:49 -0700
Commit message: Merge pull request #2941 from BerriAI/litellm_fix_sec_report

[FIX] -  Security issue Server-Side Template Injection in /completions endpoint in
CVE-2016-10189: NULL Pointer Dereference (CWE-476)
value: BitlBee before 3.5 allows remote attackers to cause a denial of service (NULL pointer dereference and crash) and possibly execute arbitrary code via a file transfer request for a contact that is not in the contact list.
CWE description: The product dereferences a pointer that it expects to be valid but is NULL.
CVSS v3 base score: 7.5
Published: 2017-03-14T14:59Z
Repository: https://github.com/bitlbee/bitlbee
Language: C
Files changed: protocols/bee_ft.c
Commit date: 2016-11-13 16:52:43 -0300
Commit message: imcb_file_send_start: handle ft attempts from non-existing users

Diff: diff --git a/protocols/bee_ft.c b/protocols/bee_ft.c
index 27fd4eac..916b2e88 100644
--- a/protocols/bee_ft.c
+++ b/protocols/bee_ft.c
@@ -28,11 +28,11 @@
 file_transfer_t *imcb_file_send_start(struct im_connection *ic, char *handle, char *file_name, size_t file_size)
 {
 	bee_t *bee = ic->bee;
 	bee_user_t *bu = bee_user_by_handle(bee, ic, handle);
 
-	if (bee->ui->ft_in_start) {
+	if (bee->ui->ft_in_start && bu) {
 		return bee->ui->ft_in_start(bee, bu, file_name, file_size);
 	} else {
 		return NULL;
 	}
 }

Vulnerable code: 	if (bee->ui->ft_in_start) {
Fixed code: 	if (bee->ui->ft_in_start && bu) {
CVE-2017-5668: NULL Pointer Dereference (CWE-476)
value: bitlbee-libpurple before 3.5.1 allows remote attackers to cause a denial of service (NULL pointer dereference and crash) and possibly execute arbitrary code via a file transfer request for a contact that is not in the contact list.  NOTE: this vulnerability exists because of an incomplete fix for CVE-2016-10189.
CWE description: The product dereferences a pointer that it expects to be valid but is NULL.
CVSS v3 base score: 9.8
Published: 2017-03-14T14:59Z
Repository: https://github.com/bitlbee/bitlbee
Language: C
Files changed: protocols/purple/ft.c
Commit date: 2017-01-29 19:40:09 -0300
Commit message: purple: Fix crash on ft requests from unknown contacts

Followup to 701ab81 (included in 3.5) which was a partial fix which only
improved things for non-libpurple file transfers (that is, just jabber)

Diff: diff --git a/protocols/purple/ft.c b/protocols/purple/ft.c
index 81fee8d0..79476ebc 100644
--- a/protocols/purple/ft.c
+++ b/protocols/purple/ft.c
@@ -143,10 +143,14 @@ static gboolean prplcb_xfer_new_send_cb(gpointer data, gint fd, b_input_conditio
 	who = buddy ? purple_buddy_get_name(buddy) : xfer->who;
 
 	/* TODO(wilmer): After spreading some more const goodness in BitlBee,
 	   remove the evil cast below. */
 	px->ft = imcb_file_send_start(ic, (char *) who, xfer->filename, xfer->size);
+
+	if (!px->ft) {
+		return FALSE;
+	}
 	px->ft->data = px;
 
 	px->ft->accept = prpl_xfer_accept;
 	px->ft->canceled = prpl_xfer_canceled;
 	px->ft->free = prpl_xfer_free;

Fixed code: 
	if (!px->ft) {
		return FALSE;
	}
CVE-2016-10536: Improper Certificate Validation (CWE-295)
value: engine.io-client is the client for engine.io, the implementation of a transport-based cross-browser/cross-device bi-directional communication layer for Socket.IO. The vulnerability is related to the way that node.js handles the `rejectUnauthorized` setting. If the value is something that evaluates to false, certificate verification will be disabled. This is problematic as engine.io-client 1.6.8 and earlier passes in an object for settings that includes the rejectUnauthorized property, whether it has been set or not. If the value has not been explicitly changed, it will be passed in as `null`, resulting in certificate verification being turned off.
CWE description: The product does not validate, or incorrectly validates, a certificate.
CVSS v3 base score: 5.9
Published: 2018-05-31T20:29Z
Repository: https://github.com/socketio/engine.io-client
Language: JavaScript
Files changed: lib/socket.js
Commit date: 2016-03-30 08:30:14 -0700
Commit message: default `rejectUnauthorized` to `true`

Diff: diff --git a/lib/socket.js b/lib/socket.js
index 9a36563..c136499 100644
--- a/lib/socket.js
+++ b/lib/socket.js
@@ -88,11 +88,11 @@ function Socket (uri, opts) {
   this.key = opts.key || null;
   this.passphrase = opts.passphrase || null;
   this.cert = opts.cert || null;
   this.ca = opts.ca || null;
   this.ciphers = opts.ciphers || null;
-  this.rejectUnauthorized = opts.rejectUnauthorized === undefined ? null : opts.rejectUnauthorized;
+  this.rejectUnauthorized = opts.rejectUnauthorized === undefined ? true : opts.rejectUnauthorized;
 
   // other options for Node.js client
   var freeGlobal = typeof global === 'object' && global;
   if (freeGlobal.global === freeGlobal) {
     if (opts.extraHeaders && Object.keys(opts.extraHeaders).length > 0) {

Vulnerable code:   this.rejectUnauthorized = opts.rejectUnauthorized === undefined ? null : opts.rejectUnauthorized;
Fixed code:   this.rejectUnauthorized = opts.rejectUnauthorized === undefined ? true : opts.rejectUnauthorized;
CVE-2011-0766: Cryptographic Issues (CWE-310)
value: The random number generator in the Crypto application before 2.0.2.2, and SSH before 2.0.5, as used in the Erlang/OTP ssh library before R14B03, uses predictable seeds based on the current time, which makes it easier for remote attackers to guess DSA host and SSH session keys.
CWE description: 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.
Published: 2011-05-31T20:55Z
Repository: https://github.com/erlang/otp
Language: Unknown
Commit date: 2011-04-20 18:19:31 +0200
Commit message: Merge branch 'maint-r14' into dev
CVE-2021-23413: Insufficient Information (NVD-CWE-noinfo)
value: This affects the package jszip before 3.7.0. Crafting a new zip file with filenames set to Object prototype values (e.g __proto__, toString, etc) results in a returned object with a modified prototype instance.
CWE description: There is insufficient information about the issue to classify it; details are unkown or unspecified.
CVSS v3 base score: 5.3
Published: 2021-07-25T13:15Z
Repository: https://github.com/Stuk/jszip
Language: JavaScript
Files changed: lib/index.js, lib/object.js
Commit date: 2021-06-14 12:29:16 +0100
Commit message: fix: Use a null prototype object for this.files

This approach is taken to prevent overriding object methods that would
exist on a normal object Object.create({})

Diff: diff --git a/lib/index.js b/lib/index.js
index b449877..b4c95ba 100644
--- a/lib/index.js
+++ b/lib/index.js
@@ -17,11 +17,14 @@ function JSZip() {
     // object containing the files :
     // {
     //   "folder/" : {...},
     //   "folder/data.txt" : {...}
     // }
-    this.files = {};
+    // NOTE: we use a null prototype because we do not
+    // want filenames like "toString" coming from a zip file
+    // to overwrite methods and attributes in a normal Object.
+    this.files = Object.create(null);
 
     this.comment = null;
 
     // Where we are in the hierarchy
     this.root = "";
diff --git a/lib/object.js b/lib/object.js
index 1c9d8e8..aec3db7 100644
--- a/lib/object.js
+++ b/lib/object.js
@@ -177,20 +177,20 @@ var out = {
      * function (relativePath, file) {...}
      * It takes 2 arguments : the relative path and the file.
      */
     forEach: function(cb) {
         var filename, relativePath, file;
+        /* jshint ignore:start */
+        // ignore warning about unwanted properties because this.files is a null prototype object
         for (filename in this.files) {
-            if (!this.files.hasOwnProperty(filename)) {
-                continue;
-            }
             file = this.files[filename];
             relativePath = filename.slice(this.root.length, filename.length);
             if (relativePath && filename.slice(0, this.root.length) === this.root) { // the file is in the current root
                 cb(relativePath, file); // TODO reverse the parameters ? need to be clean AND consistent with the filter search fn...
             }
         }
+        /* jshint ignore:end */
     },
 
     /**
      * Filter nested files/folders with the specified function.
      * @param {Function} search the predicate to use :

Vulnerable code:     this.files = {};
            if (!this.files.hasOwnProperty(filename)) {
                continue;
            }
Fixed code:     // NOTE: we use a null prototype because we do not
    // want filenames like "toString" coming from a zip file
    // to overwrite methods and attributes in a normal Object.
    this.files = Object.create(null);
        /* jshint ignore:start */
        // ignore warning about unwanted properties because this.files is a null prototype object
        /* jshint ignore:end */
CVE-2015-8791: Exposure of Sensitive Information to an Unauthorized Actor (CWE-200)
value: The EbmlElement::ReadCodedSizeValue function in libEBML before 1.3.3 allows context-dependent attackers to obtain sensitive information from process heap memory via a crafted length value in an EBML id, which triggers an invalid memory access.
CWE description: The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
CVSS v3 base score: 4.3
Published: 2016-01-29T19:59Z
Repository: https://github.com/Matroska-Org/libebml
Language: Other
Files changed: ChangeLog, src/EbmlElement.cpp
Commit date: 2015-10-20 14:54:55 +0200
Commit message: EbmlElement: don't read beyond end of buffer when reading variable length integers

Diff: diff --git a/ChangeLog b/ChangeLog
index a5139c4..3fb53d4 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,7 +1,13 @@
 2015-10-20  Moritz Bunkus  <moritz@bunkus.org>
 
+        * EbmlElement::ReadCodedSizeValue(): Fixed an invalid memory
+        access. When reading a EBML variable length integer value a read
+        access beyond the end of the available buffer was possible if
+        fewer bytes were available than indicated by the first byte
+        resulting in a heap information leak.
+
         * EbmlUnicodeString::UpdateFromUTF8(): Fixed an invalid memory
         access. When reading from a UTF-8 string in which the length
         indicated by a UTF-8 character's first byte exceeds the string's
         actual number of bytes the parser would access beyond the end of
         the string resulting in a heap information leak. Fixes the issue
diff --git a/src/EbmlElement.cpp b/src/EbmlElement.cpp
index 39eb6f0..d25abe8 100644
--- a/src/EbmlElement.cpp
+++ b/src/EbmlElement.cpp
@@ -148,10 +148,15 @@ uint64 ReadCodedSizeValue(const binary * InBuffer, uint32 & BufferSize, uint64 &
   for (SizeIdx = 0; SizeIdx < BufferSize && SizeIdx < 8; SizeIdx++) {
     if (InBuffer[0] & (SizeBitMask >> SizeIdx)) {
       // ID found
       PossibleSizeLength = SizeIdx + 1;
       SizeBitMask >>= SizeIdx;
+
+      // Guard against invalid memory accesses with incomplete IDs.
+      if (PossibleSizeLength > BufferSize)
+        break;
+
       for (SizeIdx = 0; SizeIdx < PossibleSizeLength; SizeIdx++) {
         PossibleSize[SizeIdx] = InBuffer[SizeIdx];
       }
       for (SizeIdx = 0; SizeIdx < PossibleSizeLength - 1; SizeIdx++) {
         Result <<= 7;

Fixed code:         * EbmlElement::ReadCodedSizeValue(): Fixed an invalid memory
        access. When reading a EBML variable length integer value a read
        access beyond the end of the available buffer was possible if
        fewer bytes were available than indicated by the first byte
        resulting in a heap information leak.


      // Guard against invalid memory accesses with incomplete IDs.
      if (PossibleSizeLength > BufferSize)
        break;
CVE-2019-13615: Out-of-bounds Read (CWE-125)
value: libebml before 1.3.6, as used in the MKV module in VideoLAN VLC Media Player binaries before 3.0.3, has a heap-based buffer over-read in EbmlElement::FindNextElement.
CWE description: The product reads data past the end, or before the beginning, of the intended buffer.
CVSS v3 base score: 5.5
Published: 2019-07-16T17:15Z
Repository: https://github.com/Matroska-Org/libebml
Language: C++
Files changed: src/EbmlElement.cpp
Commit date: 2017-11-27 09:48:32 +0100
Commit message: Check the max size to read before actually reading

The size check waas also missing from the length parsing

Diff: diff --git a/src/EbmlElement.cpp b/src/EbmlElement.cpp
index 143f439..ae4441e 100644
--- a/src/EbmlElement.cpp
+++ b/src/EbmlElement.cpp
@@ -402,16 +402,18 @@ EbmlElement * EbmlElement::FindNextElement(IOCallback & DataStream, const EbmlSe
         // ID not found
         // shift left the read octets
         memmove(&PossibleIdNSize[0],&PossibleIdNSize[1], --ReadIndex);
       }
 
+      if (MaxDataSize <= ReadSize)
+        break;
       if (DataStream.read(&PossibleIdNSize[ReadIndex++], 1) == 0) {
         return NULL; // no more data ?
       }
       ReadSize++;
 
-    } while (!bFound && MaxDataSize > ReadSize);
+    } while (!bFound);
 
     if (!bFound)
       // we reached the maximum we could read without a proper ID
       return NULL;
 
@@ -430,10 +432,14 @@ EbmlElement * EbmlElement::FindNextElement(IOCallback & DataStream, const EbmlSe
       }
       if (PossibleSizeLength >= 8) {
         bFound = false;
         break;
       }
+      if (MaxDataSize <= ReadSize) {
+        bFound = false;
+        break;
+      }
       if( DataStream.read( &PossibleIdNSize[SizeIdx++], 1 ) == 0 ) {
         return NULL; // no more data ?
       }
       ReadSize++;
       PossibleSizeLength++;

Vulnerable code:     } while (!bFound && MaxDataSize > ReadSize);
Fixed code:       if (MaxDataSize <= ReadSize)
        break;
    } while (!bFound);
      if (MaxDataSize <= ReadSize) {
        bFound = false;
        break;
      }
CVE-2019-13615: Out-of-bounds Read (CWE-125)
value: libebml before 1.3.6, as used in the MKV module in VideoLAN VLC Media Player binaries before 3.0.3, has a heap-based buffer over-read in EbmlElement::FindNextElement.
CWE description: The product reads data past the end, or before the beginning, of the intended buffer.
CVSS v3 base score: 5.5
Published: 2019-07-16T17:15Z
Repository: https://github.com/Matroska-Org/libebml
Language: C++
Files changed: src/EbmlElement.cpp
Commit date: 2018-01-22 15:43:13 +0100
Commit message: Exit the max size loop when there's nothing left possible to find

DataStream.getFilePointer() is not correct in this context. It might force to
exit too early.

Diff: diff --git a/src/EbmlElement.cpp b/src/EbmlElement.cpp
index ac0be41..061074b 100644
--- a/src/EbmlElement.cpp
+++ b/src/EbmlElement.cpp
@@ -476,11 +476,11 @@ EbmlElement * EbmlElement::FindNextElement(IOCallback & DataStream, const EbmlSe
 
     // recover all the data in the buffer minus one byte
     ReadIndex = SizeIdx - 1;
     memmove(&PossibleIdNSize[0], &PossibleIdNSize[1], ReadIndex);
     UpperLevel = UpperLevel_original;
-  } while ( MaxDataSize > DataStream.getFilePointer() - SizeIdx + PossibleID_Length );
+  } while ( MaxDataSize >= ReadSize );
 
   return NULL;
 }
 
 /*!

Vulnerable code:   } while ( MaxDataSize > DataStream.getFilePointer() - SizeIdx + PossibleID_Length );
Fixed code:   } while ( MaxDataSize >= ReadSize );
CVE-2022-36007: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') (CWE-22)
value: Venice is a Clojure inspired sandboxed Lisp dialect with excellent Java interoperability. A partial path traversal issue exists within the functions `load-file` and `load-resource`. These functions can be limited to load files from a list of load paths. Assuming Venice has been configured with the load paths: `[ "/Users/foo/resources" ]` When passing **relative** paths to these two vulnerable functions everything is fine: `(load-resource "test.png")` => loads the file "/Users/foo/resources/test.png" `(load-resource "../resources-alt/test.png")` => rejected, outside the load path When passing **absolute** paths to these two vulnerable functions Venice may return files outside the configured load paths: `(load-resource "/Users/foo/resources/test.png")` => loads the file "/Users/foo/resources/test.png" `(load-resource "/Users/foo/resources-alt/test.png")` => loads the file "/Users/foo/resources-alt/test.png" !!! The latter call suffers from the _Partial Path Traversal_ vulnerability. This issue’s scope is limited to absolute paths whose name prefix matches a load path. E.g. for a load-path `"/Users/foo/resources"`, the actor can cause loading a resource also from `"/Users/foo/resources-alt"`, but not from `"/Users/foo/images"`. Versions of Venice before and including v1.10.17 are affected by this issue. Upgrade to Venice >= 1.10.18, if you are on a version < 1.10.18. There are currently no known workarounds.
CWE description: 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.
CVSS v3 base score: 3.3
Published: 2022-08-15T11:21Z
Repository: https://github.com/jlangch/venice
Language: Unknown
Commit date: 2022-07-29 21:14:00 +0200
Commit message: Merge pull request #4 from BulkSecurityGeneratorProjectV2/fix/JLL/partial-path-traversal-vulnerability

[SECURITY] Fix Partial Path Traversal Vulnerability
CVE-2016-7143: Improper Authorization (CWE-285)
value: The m_authenticate function in modules/m_sasl.c in Charybdis before 3.5.3 allows remote attackers to spoof certificate fingerprints and consequently log in as another user via a crafted AUTHENTICATE parameter.
CWE description: The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.
CVSS v3 base score: 8.1
Published: 2016-09-21T14:25Z
Repository: https://github.com/charybdis-ircd/charybdis
Language: C
Files changed: modules/m_sasl.c
Commit date: 2016-09-03 17:28:41 +0000
Commit message: SASL: Disallow beginning : and space anywhere in AUTHENTICATE parameter

This is a FIX FOR A SECURITY VULNERABILITY. All Charybdis users must
apply this fix if you support SASL on your servers, or unload m_sasl.so
in the meantime.

Diff: diff --git a/modules/m_sasl.c b/modules/m_sasl.c
index 38c7bae..93c5a04 100644
--- a/modules/m_sasl.c
+++ b/modules/m_sasl.c
@@ -89,10 +89,16 @@ m_authenticate(struct Client *client_p, struct Client *source_p,
 	{
 		exit_client(client_p, client_p, client_p, "Mixing client and server protocol");
 		return 0;
 	}
 
+	if (*parv[1] == ':' || strchr(parv[1], ' '))
+	{
+		exit_client(client_p, client_p, client_p, "Malformed AUTHENTICATE");
+		return 0;
+	}
+
 	saslserv_p = find_named_client(ConfigFileEntry.sasl_service);
 	if (saslserv_p == NULL || !IsService(saslserv_p))
 	{
 		sendto_one(source_p, form_str(ERR_SASLABORTED), me.name, EmptyString(source_p->name) ? "*" : source_p->name);
 		return 0;

Fixed code: 	if (*parv[1] == ':' || strchr(parv[1], ' '))
	{
		exit_client(client_p, client_p, client_p, "Malformed AUTHENTICATE");
		return 0;
	}
CVE-2020-26213: NULL Pointer Dereference (CWE-476)
value: In teler before version 0.0.1, if you run teler inside a Docker container and encounter `errors.Exit` function, it will cause denial-of-service (`SIGSEGV`) because it doesn't get process ID and process group ID of teler properly to kills. The issue is patched in teler 0.0.1 and 0.0.1-dev5.1.
CWE description: The product dereferences a pointer that it expects to be valid but is NULL.
CVSS v3 base score: 7.5
Published: 2020-11-06T17:15Z
Repository: https://github.com/kitabisa/teler
Language: Go
Files changed: pkg/errors/abort.go
Commit date: 2020-11-02 21:09:38 +0700
Commit message: :hammer: Fix segmentation fault of syscall

If teler is run via the docker image, the syscall function cannot allocate and return a nil pointer to address.

Diff: diff --git a/pkg/errors/abort.go b/pkg/errors/abort.go
index 736ce7b..97220ef 100644
--- a/pkg/errors/abort.go
+++ b/pkg/errors/abort.go
@@ -1,13 +1,20 @@
 // +build !windows
 
 package errors
 
-import "syscall"
+import (
+	"os"
+	"syscall"
+)
 
 // Abort will terminate & sends SIGTERM to process
 func Abort(i ...int) {
+	if _, err := os.Stat("/.dockerenv"); err == nil {
+		os.Exit(i[0])
+	}
+
 	pgid, err := syscall.Getpgid(syscall.Getpid())
 	if err != nil {
 		Exit(err.Error())
 	}
 

Vulnerable code: import "syscall"
Fixed code: import (
	"os"
	"syscall"
)
	if _, err := os.Stat("/.dockerenv"); err == nil {
		os.Exit(i[0])
	}
CVE-2013-7444: Exposure of Sensitive Information to an Unauthorized Actor (CWE-200)
value: The Special:Contributions page in MediaWiki before 1.22.0 allows remote attackers to determine if an IP is autoblocked via the "Change block" text.
CWE description: The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
Published: 2015-09-01T14:59Z
Repository: https://github.com/wikimedia/mediawiki
Language: PHP
Files changed: includes/specials/SpecialContributions.php
Commit date: 2013-07-15 22:35:11 -0700
Commit message: Prevent Special:Contributions from indicating that an IP address is autoblocked

If an IP address was autoblocked in the userlinks, sysops would see
"change block" and "unblock", indicating that the IP is autoblocked.

Now Special:Contributions will only display "change block" if the user
is blocked and the block type is not Block::TYPE_AUTO. This is the same
check which is used above when deciding whether to display the
block log extract.

Bug: 46457
Change-Id: I43047059cb67527d5296322ac17fe798db917bec

Diff: diff --git a/includes/specials/SpecialContributions.php b/includes/specials/SpecialContributions.php
index 7a3e7c80d1..614bd3ec41 100644
--- a/includes/specials/SpecialContributions.php
+++ b/includes/specials/SpecialContributions.php
@@ -296,11 +296,11 @@ class SpecialContributions extends SpecialPage {
 
 		$tools[] = Linker::link( $talkpage, $this->msg( 'sp-contributions-talk' )->escaped() );
 
 		if ( ( $id !== null ) || ( $id === null && IP::isIPAddress( $username ) ) ) {
 			if ( $this->getUser()->isAllowed( 'block' ) ) { # Block / Change block / Unblock links
-				if ( $target->isBlocked() ) {
+				if ( $target->isBlocked() && $target->getBlock()->getType() != Block::TYPE_AUTO ) {
 					$tools[] = Linker::linkKnown( # Change block link
 						SpecialPage::getTitleFor( 'Block', $username ),
 						$this->msg( 'change-blocklink' )->escaped()
 					);
 					$tools[] = Linker::linkKnown( # Unblock link

Vulnerable code: 				if ( $target->isBlocked() ) {
Fixed code: 				if ( $target->isBlocked() && $target->getBlock()->getType() != Block::TYPE_AUTO ) {
CVE-2015-6727: Exposure of Sensitive Information to an Unauthorized Actor (CWE-200)
value: The Special:DeletedContributions page in MediaWiki before 1.23.10, 1.24.x before 1.24.3, and 1.25.x before 1.25.2 allows remote attackers to determine if an IP is autoblocked via the "Change block" text.
CWE description: The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
Published: 2015-09-01T14:59Z
Repository: https://github.com/wikimedia/mediawiki
Language: PHP
Files changed: includes/specials/SpecialDeletedContributions.php
Commit date: 2015-08-11 07:17:30 -0700
Commit message: SECURITY: Don't disclose if an IP is autoblocked on Special:DeletedContributions

Same patch as dc2966bd05b, just for Special:DeletedContributions this
time.

Bug: T106893
Change-Id: I2089b21fc379b612fe9bf087b5f4ea75052bdbd3

Diff: diff --git a/includes/specials/SpecialDeletedContributions.php b/includes/specials/SpecialDeletedContributions.php
index 8c7f0c89c1..44352a78b5 100644
--- a/includes/specials/SpecialDeletedContributions.php
+++ b/includes/specials/SpecialDeletedContributions.php
@@ -475,11 +475,11 @@ class DeletedContributionsPage extends SpecialPage {
 			# Talk page link
 			$tools[] = Linker::link( $talk, $this->msg( 'sp-contributions-talk' )->escaped() );
 			if ( ( $id !== null ) || ( $id === null && IP::isIPAddress( $nt->getText() ) ) ) {
 				# Block / Change block / Unblock links
 				if ( $this->getUser()->isAllowed( 'block' ) ) {
-					if ( $userObj->isBlocked() ) {
+					if ( $userObj->isBlocked() && $userObj->getBlock()->getType() !== Block::TYPE_AUTO ) {
 						$tools[] = Linker::linkKnown( # Change block link
 							SpecialPage::getTitleFor( 'Block', $nt->getDBkey() ),
 							$this->msg( 'change-blocklink' )->escaped()
 						);
 						$tools[] = Linker::linkKnown( # Unblock link

Vulnerable code: 					if ( $userObj->isBlocked() ) {
Fixed code: 					if ( $userObj->isBlocked() && $userObj->getBlock()->getType() !== Block::TYPE_AUTO ) {