hitoshura25/cvefixes huggingface dataset:
CVE-2023-41037 (Unknown, published 2023-08-29T17:15Z)
Description: value: OpenPGP.js is a JavaScript implementation of the OpenPGP protocol. In affected versions OpenPGP Cleartext Signed Messages are cryptographically signed messages where the signed text is readable without special tools. These messages typically contain a "Hash: ..." header declaring the hash algorithm used to compute the signature digest. OpenPGP.js up to v5.9.0 ignored any data preceding the "Hash: ..." texts when verifying the signature. As a result, malicious parties could add arbitrary text to a third-party Cleartext Signed Message, to lead the victim to believe that the arbitrary text was signed. A user or application is vulnerable to said attack vector if it verifies the CleartextMessage by only checking the returned `verified` property, discarding the associated `data` information, and instead _visually trusting_ the contents of the original message. Since `verificationResult.data` would always contain the actual signed data, users and apps that check this information are not vulnerable. Similarly, given a CleartextMessage object, retrieving the data using `getText()` or the `text` field returns only the contents that are considered when verifying the signature. Finally, re-armoring a CleartextMessage object (using `armor()` will also result in a "sanitised" version, with the extraneous text being removed. This issue has been addressed in version 5.10.1 (current stable version) which will reject messages when calling `openpgp.readCleartextMessage()` and in version 4.10.11 (legacy version) which will will reject messages when calling `openpgp.cleartext.readArmored()`. Users are advised to upgrade. Users unable to upgrade should check the contents of `verificationResult.data` to see what data was actually signed, rather than visually trusting the contents of the armored message.
Severity: nan (CVSS v3 base score: 4.3)
Weakness: CWE-347 \u2014 Improper Verification of Cryptographic Signature
The product does not verify, or incorrectly verifies, the cryptographic signature for data.
Repository: https://github.com/openpgpjs/openpgpjs
Files changed:
Commit message: Merge pull request from GHSA-ch3c-v47x-4pgp

Reject cleartext messages with extraneous data preceeding hash header

Vulnerable code:

Fixed code:
CVE-2023-26149 (Unknown, published 2023-09-28T05:15Z)
Description: value: Versions of the package quill-mention before 4.0.0 are vulnerable to Cross-site Scripting (XSS) due to improper user-input sanitization, via the renderList function. **Note:**If the mentions list is sourced from unsafe (user-sourced) data, this might allow an injection attack when a Quill user hits @.
Severity: nan (CVSS v3 base score: 6.1)
Weakness: CWE-79 \u2014 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.
Repository: https://github.com/quill-mention/quill-mention
Files changed:
Commit message: Merge pull request #341 from SimplyBinary/fix-inner-html

Fix innerHTML XSS vulnerability

Vulnerable code:

Fixed code:
CVE-2024-27081 (Python, published 2024-02-26T17:15Z)
Description: value: ESPHome is a system to control your ESP8266/ESP32. A security misconfiguration in the edit configuration file API in the dashboard component of ESPHome version 2023.12.9 (command line installation) allows authenticated remote attackers to read and write arbitrary files under the configuration directory rendering remote code execution possible.  This vulnerability is patched in 2024.2.1.

Severity: nan (CVSS v3 base score: )
Weakness: NVD-CWE-noinfo \u2014 Insufficient Information
There is insufficient information about the issue to classify it; details are unkown or unspecified.
Repository: https://github.com/esphome/esphome
Files changed:
esphome/dashboard/web_server.py
Commit message: Merge pull request from GHSA-8p25-3q46-8q2p


Vulnerable code:
        loop = asyncio.get_running_loop()
        config_file = settings.rel_path(configuration)
        await loop.run_in_executor(
            None, self._write_file, config_file, self.request.body
        )

Fixed code:
        if not configuration.endswith((".yaml", ".yml")):
            self.send_error(404)
            return

        if Path(filename).resolve().parent != settings.absolute_config_dir:
            self.send_error(404)
            return

        loop = asyncio.get_running_loop()
        if not configuration.endswith((".yaml", ".yml")):
            self.send_error(404)
            return

        filename = settings.rel_path(configuration)
        if Path(filename).resolve().parent != settings.absolute_config_dir:
            self.send_error(404)
            return

        await loop.run_in_executor(None, self._write_file, filename, self.request.body)
CVE-2024-27287 (Python, published 2024-03-06T19:15Z)
Description: value: ESPHome is a system to control your ESP8266/ESP32 for Home Automation systems. Starting in version 2023.12.9 and prior to version 2024.2.2, editing the configuration file API in dashboard component of ESPHome version 2023.12.9 (command line installation and Home Assistant add-on) serves unsanitized data with `Content-Type: text/html; charset=UTF-8`, allowing a remote authenticated user to inject arbitrary web script and exfiltrate session cookies via Cross-Site scripting. It is possible for a malicious authenticated user to inject arbitrary Javascript in configuration files using a POST request to the /edit endpoint, the configuration parameter allows to specify the file to write. To trigger the XSS vulnerability, the victim must visit the page` /edit?configuration=[xss file]`. Abusing this vulnerability a malicious actor could perform operations on the dashboard on the behalf of a logged user, access sensitive information, create, edit and delete configuration files and flash firmware on managed boards.
In addition to this, cookies are not correctly secured, allowing the exfiltration of session cookie values. Version 2024.2.2 contains a patch for this issue.

Severity: nan (CVSS v3 base score: )
Weakness: NVD-CWE-noinfo \u2014 Insufficient Information
There is insufficient information about the issue to classify it; details are unkown or unspecified.
Repository: https://github.com/esphome/esphome
Files changed:
esphome/dashboard/web_server.py
Commit message: Merge pull request from GHSA-9p43-hj5j-96h5



Vulnerable code:

Fixed code:
            self.set_header("Content-Type", "application/yaml")
CVE-2017-8831 (C, published 2017-05-08T06:29Z)
Description: value: The saa7164_bus_get function in drivers/media/pci/saa7164/saa7164-bus.c in the Linux kernel through 4.11.5 allows local users to cause a denial of service (out-of-bounds array access) or possibly have unspecified other impact by changing a certain sequence-number value, aka a "double fetch" vulnerability.
Severity: MEDIUM (CVSS v3 base score: 6.4)
Weakness: CWE-125 \u2014 Out-of-bounds Read
The product reads data past the end, or before the beginning, of the intended buffer.
Repository: https://github.com/stoth68000/media-tree
Files changed:
drivers/media/pci/saa7164/saa7164-bus.c
Commit message: [PATCH] saa7164: Bug - Double fetch PCIe access condition

Avoid a double fetch by reusing the values from the prior transfer.

Originally reported via https://bugzilla.kernel.org/show_bug.cgi?id=195559

Thanks to Pengfei Wang <wpengfeinudt@gmail.com> for reporting.

Signed-off-by: Steven Toth <stoth@kernellabs.com>


Vulnerable code:
		memcpy(msg, &msg_tmp, sizeof(*msg));
			/* msg wraps around the ring */
			memcpy_fromio(msg, bus->m_pdwGetRing + curr_grp, space_rem);
			memcpy_fromio((u8 *)msg + space_rem, bus->m_pdwGetRing,
				sizeof(*msg) - space_rem);
			memcpy_fromio(msg, bus->m_pdwGetRing + curr_grp, sizeof(*msg));
			memcpy_fromio(msg, bus->m_pdwGetRing + curr_grp, sizeof(*msg));
		memcpy_fromio(msg, bus->m_pdwGetRing + curr_grp, sizeof(*msg));
	/* Convert from little endian to CPU */
	msg->size = le16_to_cpu((__force __le16)msg->size);
	msg->command = le32_to_cpu((__force __le32)msg->command);
	msg->controlselector = le16_to_cpu((__force __le16)msg->controlselector);

Fixed code:
	memcpy(msg, &msg_tmp, sizeof(*msg));
CVE-2016-7553 (Perl, published 2017-02-27T22:59Z)
Description: value: The buf.pl script before 2.20 in Irssi before 0.8.20 uses weak permissions for the scrollbuffer dump file created between upgrades, which might allow local users to obtain sensitive information from private chat conversations by reading the file.
Severity: LOW (CVSS v3 base score: 3.3)
Weakness: CWE-275 \u2014 Permission Issues
Weaknesses in this category are related to improper assignment or handling of permissions.
Repository: https://github.com/irssi/scripts.irssi.org
Files changed:
scripts/buf.pl
Commit message: Fix disclosure via filesystem

buf.pl restores the scrollbuffer between "/upgrade"s by writing the
contents to a file, and reading that after the new process was spawned.
Through that file, the contents of (private) chat conversations may leak to
other users.

Careful users with a limited umask (e.g. 077) are not affected by this bug.
However, most Linux systems default to a umask of 022, meaning that files
written without further restricting the permissions, are readable by any
user.

This patch sets a safer umask of 077 for the scrollbuffer dump, and will
remove the temporary file after use to further reduce the attack surface.
Additionally, it will remove any remaining temporary scrollbuffer file left
in place, like those written by previous versions of the script.


Vulnerable code:
$VERSION = '2.13';
    changed	=> 'Mon May 13 19:41 CET 2002',
    changes	=> 'Severe formatting bug removed * oops, I ' .
                   'exposed Irssi to ircII foolishness * sorry ' .
		   '** removed logging stuff (this is a fix)',
    open BUF, q{>}, sprintf('%s/scrollbuffer', get_irssi_dir) or die $!;
    print BUF join("\0", map $_->{server}->{address} . $_->{name}, channels), "\n";
	printf BUF "%s:%s\n%s", $window->{refnum}, $lines, $buf;
    close BUF;
    open BUF, q{<}, sprintf('%s/scrollbuffer', get_irssi_dir) or die $!;
    my @suppress = split /\0/, <BUF>;
    while (my $bla = <BUF>){
	    <BUF> for 1..$lines;
	$buf .= <BUF> for 1..$lines;

Fixed code:
$VERSION = '2.20';
    changed	=> 'Thu Sep 22 01:37 CEST 2016',
    changes	=> 'Fixed file permissions (leaked everything via filesystem)',
sub _filename { sprintf '%s/scrollbuffer', get_irssi_dir }

    my $fn = _filename;
    my $old_umask = umask 0077;
    open my $fh, q{>}, $fn or die "open $fn: $!";
    umask $old_umask;

    print $fh join("\0", map $_->{server}->{address} . $_->{name}, channels), "\n";
	printf $fh "%s:%s\n%s", $window->{refnum}, $lines, $buf;
    close $fh;
    my $fn = _filename;
    open my $fh, q{<}, $fn or die "open $fn: $!";
    unlink $fn or warn "unlink $fn: $!";

    my @suppress = split /\0/, readline $fh;
    while (my $bla = readline $fh){
	    readline $fh for 1..$lines;
	$buf .= readline $fh for 1..$lines;

# Remove any left-over file. If 'session' doesn't exist (created by irssi
# during /UPGRADE), neither should our file.
unless (-e sprintf('%s/session', get_irssi_dir)) {
    my $fn = _filename;
    unlink $fn or warn "unlink $fn: $!" if -e $fn;
}
CVE-2020-5257 (Ruby, published 2020-03-13T21:15Z)
Description: value: In Administrate (rubygem) before version 0.13.0, when sorting by attributes on a dashboard, the direction parameter was not validated before being interpolated into the SQL query. This could present a SQL injection if the attacker were able to modify the `direction` parameter and bypass ActiveRecord SQL protections. Whilst this does have a high-impact, to exploit this you need access to the Administrate dashboards, which we would expect to be behind authentication. This is patched in wersion 0.13.0.
Severity: MEDIUM (CVSS v3 base score: 8.1)
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/thoughtbot/administrate
Files changed:
lib/administrate/order.rb
spec/lib/administrate/order_spec.rb
Commit message: Merge pull request from GHSA-2p5p-m353-833w

Previously, order parameters were passed directly through to the query.
This meant that passing in `foo` via a URL string would try and sort by
`foo`.

Vulnerable code:
      @direction = direction || :asc
      direction.to_sym == :asc ? :desc : :asc

Fixed code:
      @direction = sanitize_direction(direction)
    def sanitize_direction(direction)
      %w[asc desc].include?(direction.to_s) ? direction.to_sym : :asc
    end

      direction == :asc ? :desc : :asc

      it "sanitizes arbitary direction parameters" do
        order = Administrate::Order.new(:name, :foo)
        relation = relation_with_column(:name)
        allow(relation).to receive(:reorder).and_return(relation)

        ordered = order.apply(relation)

        expect(relation).to have_received(:reorder).with("table_name.name asc")
        expect(ordered).to eq(relation)
      end
CVE-2013-4244 (Other, published 2013-09-28T19:55Z)
Description: value: The LZW decompressor in the gif2tiff tool in libtiff 4.0.3 and earlier allows context-dependent attackers to cause a denial of service (out-of-bounds write and crash) or possibly execute arbitrary code via a crafted GIF image.
Severity: MEDIUM (CVSS v3 base score: )
Weakness: CWE-119 \u2014 Improper Restriction of Operations within the Bounds of a Memory Buffer
The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.
Repository: https://github.com/vadz/libtiff
Files changed:
ChangeLog
tools/gif2tiff.c
Commit message: fix possible OOB write in gif2tiff.c


Vulnerable code:

Fixed code:
2013-08-14  Frank Warmerdam  <warmerdam@pobox.com>

	* tools/gif2tiff.c: fix possible OOB write (#2452, CVE-2013-4244) 

        if (code >= clear) {
            fprintf(stderr, "bad input: code=%d is larger than clear=%d\n",code, clear);
            return 0;
        }
CVE-2014-8130 (C, published 2018-03-12T02:29Z)
Description: value: The _TIFFmalloc function in tif_unix.c in LibTIFF 4.0.3 does not reject a zero size, which allows remote attackers to cause a denial of service (divide-by-zero error and application crash) via a crafted TIFF image that is mishandled by the TIFFWriteScanline function in tif_write.c, as demonstrated by tiffdither.
Severity: MEDIUM (CVSS v3 base score: 6.5)
Weakness: CWE-369 \u2014 Divide By Zero
The product divides a value by zero.
Repository: https://github.com/vadz/libtiff
Files changed:
ChangeLog
libtiff/tif_unix.c
libtiff/tif_vms.c
libtiff/tif_win32.c
Commit message: * libtiff/tif_{unix,vms,win32}.c (_TIFFmalloc): ANSI C does not
require malloc() to return NULL pointer if requested allocation
size is zero.  Assure that _TIFFmalloc does.


Vulnerable code:

Fixed code:
2012-11-18  Bob Friesenhahn  <bfriesen@simple.dallas.tx.us>

	* libtiff/tif_{unix,vms,win32}.c (_TIFFmalloc): ANSI C does not
	require malloc() to return NULL pointer if requested allocation
	size is zero.  Assure that _TIFFmalloc does.

        if (s == 0)
                return ((void *) NULL);

        if (s == 0)
                return ((void *) NULL);

        if (s == 0)
                return ((void *) NULL);
CVE-2015-8784 (Other, published 2016-04-13T17:59Z)
Description: value: The NeXTDecode function in tif_next.c in LibTIFF allows remote attackers to cause a denial of service (out-of-bounds write) via a crafted TIFF image, as demonstrated by libtiff5.tif.
Severity: MEDIUM (CVSS v3 base score: 6.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/vadz/libtiff
Files changed:
ChangeLog
libtiff/tif_next.c
Commit message: * libtiff/tif_next.c: fix potential out-of-bound write in NeXTDecode()
triggered by http://lcamtuf.coredump.cx/afl/vulns/libtiff5.tif
(bugzilla #2508)


Vulnerable code:
	case 3:	*op++ |= (v);	   break;	\
				while (n-- > 0 && npixels < imagewidth)

Fixed code:
2015-12-27  Even Rouault <even.rouault at spatialys.com>

	* libtiff/tif_next.c: fix potential out-of-bound write in NeXTDecode()
	triggered by http://lcamtuf.coredump.cx/afl/vulns/libtiff5.tif
	(bugzilla #2508)

	case 3:	*op++ |= (v);	   op_offset++; break;	\
            tmsize_t op_offset = 0;
				while (n-- > 0 && npixels < imagewidth && op_offset < scanline)
                if (op_offset >= scanline ) {
                    TIFFErrorExt(tif->tif_clientdata, module, "Invalid data for scanline %ld",
                        (long) tif->tif_row);
                    return (0);
                }
CVE-2016-10092 (Other, published 2017-03-01T15:59Z)
Description: value: Heap-based buffer overflow in the readContigStripsIntoBuffer function in tif_unix.c in LibTIFF 4.0.7, 3.9.3, 3.9.4, 3.9.5, 3.9.6, 3.9.7, 4.0.0alpha4, 4.0.0alpha5, 4.0.0alpha6, 4.0.0beta7, 4.0.0, 4.0.1, 4.0.2, 4.0.3, 4.0.4, 4.0.4beta, 4.0.5 and 4.0.6 allows remote attackers to have unspecified impact via a crafted image.
Severity: MEDIUM (CVSS v3 base score: 7.8)
Weakness: CWE-119 \u2014 Improper Restriction of Operations within the Bounds of a Memory Buffer
The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.
Repository: https://github.com/vadz/libtiff
Files changed:
ChangeLog
tools/tiffcrop.c
Commit message: * tools/tiffcrop.c: fix readContigStripsIntoBuffer() in -i (ignore) mode so
that the output buffer is correctly incremented to avoid write outside bounds.
Reported by Agostino Sarubbo.
Fixes http://bugzilla.maptools.org/show_bug.cgi?id=2620


Vulnerable code:
                bufp += bytes_read;

Fixed code:
2016-12-03 Even Rouault <even.rouault at spatialys.com>

	* tools/tiffcrop.c: fix readContigStripsIntoBuffer() in -i (ignore) mode so
	that the output buffer is correctly incremented to avoid write outside bounds.
	Reported by Agostino Sarubbo.
	Fixes http://bugzilla.maptools.org/show_bug.cgi?id=2620

                bufp += stripsize;
CVE-2016-10093 (Other, published 2017-03-01T15:59Z)
Description: value: Integer overflow in tools/tiffcp.c in LibTIFF 4.0.7, 3.9.3, 3.9.4, 3.9.5, 3.9.6, 3.9.7, 4.0.0alpha4, 4.0.0alpha5, 4.0.0alpha6, 4.0.0beta7, 4.0.0, 4.0.1, 4.0.2, 4.0.3, 4.0.4, 4.0.4beta, 4.0.5 and 4.0.6 allows remote attackers to have unspecified impact via a crafted image, which triggers a heap-based buffer overflow.
Severity: MEDIUM (CVSS v3 base score: 7.8)
Weakness: CWE-119 \u2014 Improper Restriction of Operations within the Bounds of a Memory Buffer
The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.
Repository: https://github.com/vadz/libtiff
Files changed:
ChangeLog
tools/tiffcp.c
Commit message: * tools/tiffcp.c: fix uint32 underflow/overflow that can cause heap-based
buffer overflow.
Reported by Agostino Sarubbo.
Fixes http://bugzilla.maptools.org/show_bug.cgi?id=2610


Vulnerable code:
    uint32 rows, uint32 cols, int outskew, int inskew)
	int iskew = imagew - tilew;
			if (colb + tilew > imagew) {

Fixed code:
2016-12-03 Even Rouault <even.rouault at spatialys.com>

	* tools/tiffcp.c: fix uint32 underflow/overflow that can cause heap-based
	buffer overflow.
	Reported by Agostino Sarubbo.
	Fixes http://bugzilla.maptools.org/show_bug.cgi?id=2610

    uint32 rows, uint32 cols, int outskew, int64 inskew)
	int64 iskew = (int64)imagew - (int64)tilew;
			if (colb > iskew) {
CVE-2016-10093 (Other, published 2017-03-01T15:59Z)
Description: value: Integer overflow in tools/tiffcp.c in LibTIFF 4.0.7, 3.9.3, 3.9.4, 3.9.5, 3.9.6, 3.9.7, 4.0.0alpha4, 4.0.0alpha5, 4.0.0alpha6, 4.0.0beta7, 4.0.0, 4.0.1, 4.0.2, 4.0.3, 4.0.4, 4.0.4beta, 4.0.5 and 4.0.6 allows remote attackers to have unspecified impact via a crafted image, which triggers a heap-based buffer overflow.
Severity: MEDIUM (CVSS v3 base score: 7.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/vadz/libtiff
Files changed:
ChangeLog
tools/tiffcp.c
Commit message: * tools/tiffcp.c: fix uint32 underflow/overflow that can cause heap-based
buffer overflow.
Reported by Agostino Sarubbo.
Fixes http://bugzilla.maptools.org/show_bug.cgi?id=2610


Vulnerable code:
    uint32 rows, uint32 cols, int outskew, int inskew)
	int iskew = imagew - tilew;
			if (colb + tilew > imagew) {

Fixed code:
2016-12-03 Even Rouault <even.rouault at spatialys.com>

	* tools/tiffcp.c: fix uint32 underflow/overflow that can cause heap-based
	buffer overflow.
	Reported by Agostino Sarubbo.
	Fixes http://bugzilla.maptools.org/show_bug.cgi?id=2610

    uint32 rows, uint32 cols, int outskew, int64 inskew)
	int64 iskew = (int64)imagew - (int64)tilew;
			if (colb > iskew) {
CVE-2016-10266 (Other, published 2017-03-24T19:59Z)
Description: value: LibTIFF 4.0.7 allows remote attackers to cause a denial of service (divide-by-zero error and application crash) via a crafted TIFF image, related to libtiff/tif_read.c:351:22.
Severity: MEDIUM (CVSS v3 base score: 5.5)
Weakness: CWE-369 \u2014 Divide By Zero
The product divides a value by zero.
Repository: https://github.com/vadz/libtiff
Files changed:
ChangeLog
libtiff/tif_read.c
libtiff/tiffiop.h
Commit message: * libtiff/tif_read.c, libtiff/tiffiop.h: fix uint32 overflow in
TIFFReadEncodedStrip() that caused an integer division by zero.
Reported by Agostino Sarubbo.
Fixes http://bugzilla.maptools.org/show_bug.cgi?id=2596


Vulnerable code:
	stripsperplane=((td->td_imagelength+rowsperstrip-1)/rowsperstrip);

Fixed code:
2016-12-02 Even Rouault <even.rouault at spatialys.com>

	* libtiff/tif_read.c, libtiff/tiffiop.h: fix uint32 overflow in
	TIFFReadEncodedStrip() that caused an integer division by zero.
	Reported by Agostino Sarubbo.
	Fixes http://bugzilla.maptools.org/show_bug.cgi?id=2596

	stripsperplane= TIFFhowmany_32_maxuint_compat(td->td_imagelength, rowsperstrip);
/* Variant of TIFFhowmany_32() that doesn't return 0 if x close to MAXUINT. */
/* Caution: TIFFhowmany_32_maxuint_compat(x,y)*y might overflow */
#define TIFFhowmany_32_maxuint_compat(x, y) \
			   (((uint32)(x) / (uint32)(y)) + ((((uint32)(x) % (uint32)(y)) != 0) ? 1 : 0))