hitoshura25/cvefixes huggingface dataset:
CVE-2019-14857 (Other, published 2019-11-26T12:15Z)
Description: value: A flaw was found in mod_auth_openidc before version 2.4.0.1. An open redirect issue exists in URLs with trailing slashes similar to CVE-2019-3877 in mod_auth_mellon.
Severity: MEDIUM (CVSS v3 base score: 6.1)
Weakness: CWE-601 \u2014 URL Redirection to Untrusted Site ('Open Redirect')
A web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a Redirect. This simplifies phishing attacks.
Repository: https://github.com/zmartzone/mod_auth_openidc
Files changed:
ChangeLog
configure.ac
src/mod_auth_openidc.c
Commit message: 2.4.0.2 oops

Signed-off-by: Hans Zandbelt <hans.zandbelt@zmartzone.eu>

Vulnerable code:
- release 2.4.0.1
AC_INIT([mod_auth_openidc],[2.4.0.1],[hans.zandbelt@zmartzone.eu])
	} else if (strstr(url, "/") != url) {

Fixed code:
- release 2.4.0.2
AC_INIT([mod_auth_openidc],[2.4.0.2],[hans.zandbelt@zmartzone.eu])
	} else if ((uri.hostname == NULL) && (strstr(url, "/") != url)) {
CVE-2019-20479 (Unknown, published 2020-02-20T06:15Z)
Description: value: A flaw was found in mod_auth_openidc before version 2.4.1. An open redirect issue exists in URLs with a slash and backslash at the beginning.
Severity: MEDIUM (CVSS v3 base score: 6.1)
Weakness: CWE-601 \u2014 URL Redirection to Untrusted Site ('Open Redirect')
A web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a Redirect. This simplifies phishing attacks.
Repository: https://github.com/zmartzone/mod_auth_openidc
Files changed:
Commit message: Merge pull request #453 from oss-aimoto/fix_openredirect_starting_slash_backslash

Fix open redirect starting with a slash and backslash

Vulnerable code:

Fixed code:
CVE-2021-32785 (Unknown, published 2021-07-22T22:15Z)
Description: value: mod_auth_openidc is an authentication/authorization module for the Apache 2.x HTTP server that functions as an OpenID Connect Relying Party, authenticating users against an OpenID Connect Provider. When mod_auth_openidc versions prior to 2.4.9 are configured to use an unencrypted Redis cache (`OIDCCacheEncrypt off`, `OIDCSessionType server-cache`, `OIDCCacheType redis`), `mod_auth_openidc` wrongly performed argument interpolation before passing Redis requests to `hiredis`, which would perform it again and lead to an uncontrolled format string bug. Initial assessment shows that this bug does not appear to allow gaining arbitrary code execution, but can reliably provoke a denial of service by repeatedly crashing the Apache workers. This bug has been corrected in version 2.4.9 by performing argument interpolation only once, using the `hiredis` API. As a workaround, this vulnerability can be mitigated by setting `OIDCCacheEncrypt` to `on`, as cache keys are cryptographically hashed before use when this option is enabled.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-134 \u2014 Use of Externally-Controlled Format String
The product uses a function that accepts a format string as an argument, but the format string originates from an external source.
Repository: https://github.com/zmartzone/mod_auth_openidc
Files changed:
Commit message: Merge pull request from GHSA-55r8-6w97-xxr4

use redisvCommand to avoid crash with crafted key when using Redis wi…

Vulnerable code:

Fixed code:
CVE-2021-32786 (Unknown, published 2021-07-22T22:15Z)
Description: value: mod_auth_openidc is an authentication/authorization module for the Apache 2.x HTTP server that functions as an OpenID Connect Relying Party, authenticating users against an OpenID Connect Provider. In versions prior to 2.4.9, `oidc_validate_redirect_url()` does not parse URLs the same way as most browsers do. As a result, this function can be bypassed and leads to an Open Redirect vulnerability in the logout functionality. This bug has been fixed in version 2.4.9 by replacing any backslash of the URL to redirect with slashes to address a particular breaking change between the different specifications (RFC2396 / RFC3986 and WHATWG). As a workaround, this vulnerability can be mitigated by configuring `mod_auth_openidc` to only allow redirection whose destination matches a given regular expression.
Severity: MEDIUM (CVSS v3 base score: 6.1)
Weakness: CWE-601 \u2014 URL Redirection to Untrusted Site ('Open Redirect')
A web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a Redirect. This simplifies phishing attacks.
Repository: https://github.com/zmartzone/mod_auth_openidc
Files changed:
Commit message: Merge pull request from GHSA-xm4c-5wm5-jqv7

replace potentially harmful backslashes with forward slashes when val…

Vulnerable code:

Fixed code:
CVE-2021-32792 (C, published 2021-07-26T17:15Z)
Description: value: mod_auth_openidc is an authentication/authorization module for the Apache 2.x HTTP server that functions as an OpenID Connect Relying Party, authenticating users against an OpenID Connect Provider. In mod_auth_openidc before version 2.4.9, there is an XSS vulnerability in when using `OIDCPreservePost On`.
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/zmartzone/mod_auth_openidc
Files changed:
src/mod_auth_openidc.c
src/mod_auth_openidc.h
src/util.c
Commit message: Add a function to escape Javascript characters


Vulnerable code:
									location) :
					"    </script>\n", method, original_url);
			"    </script>\n", oidc_get_redirect_uri(r, c));

Fixed code:
									oidc_util_javascript_escape(r->pool, location)) :
					"    </script>\n", method, oidc_util_javascript_escape(r->pool, original_url));
			"    </script>\n", oidc_util_javascript_escape(r->pool, oidc_get_redirect_uri(r, c)));
char *oidc_util_javascript_escape(apr_pool_t *pool, const char *input);
/*
 * JavaScript escape a string
 */
char* oidc_util_javascript_escape(apr_pool_t *pool, const char *s) {
    const char *cp;
    char *output;
    size_t outputlen;
    int i;

    if (s == NULL) {
        return NULL;
    }

    outputlen = 0;
    for (cp = s; *cp; cp++) {
        switch (*cp) {
        case '\'':
        case '"':
        case '\\':
        case '/':
        case 0x0D:
        case 0x0A:
            outputlen += 2;
            break;
        case '<':
        case '>':
            outputlen += 4;
            break;
        default:
            outputlen += 1;
            break;
        }
    }

    i = 0;
    output = apr_palloc(pool, outputlen + 1);
    for (cp = s; *cp; cp++) {
        switch (*cp) {
        case '\'':
            (void)strcpy(&output[i], "\\'");
            i += 2;
            break;
        case '"':
            (void)strcpy(&output[i], "\\\"");
            i += 2;
            break;
        case '\\':
            (void)strcpy(&output[i], "\\\\");
            i += 2;
            break;
        case '/':
            (void)strcpy(&output[i], "\\/");
            i += 2;
            break;
        case 0x0D:
            (void)strcpy(&output[i], "\\r");
            i += 2;
            break;
        case 0x0A:
            (void)strcpy(&output[i], "\\n");
            i += 2;
            break;
        case '<':
            (void)strcpy(&output[i], "\\x3c");
            i += 4;
            break;
        case '>':
            (void)strcpy(&output[i], "\\x3e");
            i += 4;
            break;
        default:
            output[i] = *cp;
            i += 1;
            break;
        }
    }
    output[i] = '\0';
    return output;
}
CVE-2021-32792 (Other, published 2021-07-26T17:15Z)
Description: value: mod_auth_openidc is an authentication/authorization module for the Apache 2.x HTTP server that functions as an OpenID Connect Relying Party, authenticating users against an OpenID Connect Provider. In mod_auth_openidc before version 2.4.9, there is an XSS vulnerability in when using `OIDCPreservePost On`.
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/zmartzone/mod_auth_openidc
Files changed:
ChangeLog
src/mod_auth_openidc.c
Commit message: avoid XSS vulnerability when using OIDCPreservePost On

and supplying URLs that contain single quotes; thanks @oss-aimoto

Signed-off-by: Hans Zandbelt <hans.zandbelt@zmartzone.eu>

Vulnerable code:
					"        document.forms[0].action = '%s';\n"

Fixed code:
06/25/2021
- avoid XSS vulnerability when using OIDCPreservePost On and supplying URLs that contain single quotes
  thanks @oss-aimoto

					"        document.forms[0].action = \"%s\";\n"
CVE-2021-28848 (C, published 2021-06-03T12:15Z)
Description: value: Mintty before 3.4.5 allows remote servers to cause a denial of service (Windows GUI hang) by telling the Mintty window to change its title repeatedly at high speed, which results in many SetWindowTextA or SetWindowTextW calls. In other words, it does not implement a usleep or similar delay upon processing a title change.
Severity: MEDIUM (CVSS v3 base score: 7.5)
Weakness: CWE-770 \u2014 Allocation of Resources Without Limits or Throttling
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.
Repository: https://github.com/mintty/mintty
Files changed:
src/termout.c
Commit message: tame some window operations, just in case


Vulnerable code:

Fixed code:
      usleep(1000);
      usleep(1000);
CVE-2021-32696 (Unknown, published 2021-06-18T20:15Z)
Description: value: The npm package "striptags" is an implementation of PHP's strip_tags in Typescript. In striptags before version 3.2.0, a type-confusion vulnerability can cause `striptags` to concatenate unsanitized strings when an array-like object is passed in as the `html` parameter. This can be abused by an attacker who can control the shape of their input, e.g. if query parameters are passed directly into the function. This can lead to a XSS.
Severity: MEDIUM (CVSS v3 base score: 5.3)
Weakness: CWE-843 \u2014 Access of Resource Using Incompatible Type ('Type Confusion')
The product allocates or initializes a resource such as a pointer, object, or variable using one type, but it later accesses that resource using a type that is incompatible with the original type.
Repository: https://github.com/ericnorris/striptags
Files changed:
Commit message: Merge pull request from GHSA-qxg5-2qff-p49r

fix: throw TypeError if 'html' is non-string argument

Vulnerable code:

Fixed code:
CVE-2017-18013 (C, published 2018-01-01T08:29Z)
Description: value: In LibTIFF 4.0.9, there is a Null-Pointer Dereference in the tif_print.c TIFFPrintDirectory function, as demonstrated by a tiffinfo crash.
Severity: MEDIUM (CVSS v3 base score: 6.5)
Weakness: CWE-476 \u2014 NULL Pointer Dereference
The product dereferences a pointer that it expects to be valid but is NULL.
Repository: https://gitlab.com/libtiff/libtiff
Files changed:
libtiff/tif_print.c
Commit message: libtiff/tif_print.c: TIFFPrintDirectory(): fix null pointer dereference on corrupted file. Fixes http://bugzilla.maptools.org/show_bug.cgi?id=2770


Vulnerable code:
			    (unsigned __int64) td->td_stripoffset[s],
			    (unsigned __int64) td->td_stripbytecount[s]);
			    (unsigned long long) td->td_stripoffset[s],
			    (unsigned long long) td->td_stripbytecount[s]);

Fixed code:
			    td->td_stripoffset ? (unsigned __int64) td->td_stripoffset[s] : 0,
			    td->td_stripbytecount ? (unsigned __int64) td->td_stripbytecount[s] : 0);
			    td->td_stripoffset ? (unsigned long long) td->td_stripoffset[s] : 0,
			    td->td_stripbytecount ? (unsigned long long) td->td_stripbytecount[s] : 0);
CVE-2018-18557 (C, published 2018-10-22T16:29Z)
Description: value: LibTIFF 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, 4.0.6, 4.0.7, 4.0.8 and 4.0.9 (with JBIG enabled) decodes arbitrarily-sized JBIG into a buffer, ignoring the buffer size, which leads to a tif_jbig.c JBIGDecode out-of-bounds write.
Severity: MEDIUM (CVSS v3 base score: 8.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://gitlab.com/libtiff/libtiff
Files changed:
libtiff/tif_jbig.c
libtiff/tif_read.c
Commit message: JBIG: fix potential out-of-bounds write in JBIGDecode()

JBIGDecode doesn't check if the user provided buffer is large enough
to store the JBIG decoded image, which can potentially cause out-of-bounds
write in the buffer.
This issue was reported and analyzed by Thomas Dullien.

Also fixes a (harmless) potential use of uninitialized memory when
tif->tif_rawsize > tif->tif_rawcc

And in case libtiff is compiled with CHUNKY_STRIP_READ_SUPPORT, make sure
that whole strip data is provided to JBIGDecode()


Vulnerable code:
	(void) size, (void) s;
		TIFFReverseBits(tif->tif_rawdata, tif->tif_rawdatasize);
	jbg_newlen(tif->tif_rawdata, (size_t)tif->tif_rawdatasize);
	decodeStatus = jbg_dec_in(&decoder, (unsigned char*)tif->tif_rawdata,
				  (size_t)tif->tif_rawdatasize, NULL);
	_TIFFmemcpy(buffer, pImage, jbg_dec_getsize(&decoder));
        if( td->td_compression == COMPRESSION_LERC )

Fixed code:
	unsigned long decodedSize;
	(void) s;
		TIFFReverseBits(tif->tif_rawcp, tif->tif_rawcc);
	jbg_newlen(tif->tif_rawcp, (size_t)tif->tif_rawcc);
	decodeStatus = jbg_dec_in(&decoder, (unsigned char*)tif->tif_rawcp,
				  (size_t)tif->tif_rawcc, NULL);
	decodedSize = jbg_dec_getsize(&decoder);
	if( (tmsize_t)decodedSize < size )
	{
	    TIFFWarningExt(tif->tif_clientdata, "JBIG",
	                   "Only decoded %lu bytes, whereas %lu requested",
	                   decodedSize, (unsigned long)size);
	}
	else if( (tmsize_t)decodedSize > size )
	{
	    TIFFErrorExt(tif->tif_clientdata, "JBIG",
	                 "Decoded %lu bytes, whereas %lu were requested",
	                 decodedSize, (unsigned long)size);
	    jbg_dec_free(&decoder);
	    return 0;
	}
	_TIFFmemcpy(buffer, pImage, decodedSize);

        tif->tif_rawcp += tif->tif_rawcc;
        tif->tif_rawcc = 0;

        if( td->td_compression == COMPRESSION_LERC ||
            td->td_compression == COMPRESSION_JBIG )
CVE-2018-5784 (C, published 2018-01-19T08:29Z)
Description: value: In LibTIFF 4.0.9, there is an uncontrolled resource consumption in the TIFFSetDirectory function of tif_dir.c. Remote attackers could leverage this vulnerability to cause a denial of service via a crafted tif file. This occurs because the declared number of directory entries is not validated against the actual number of directory entries.
Severity: MEDIUM (CVSS v3 base score: 6.5)
Weakness: CWE-400 \u2014 Uncontrolled Resource Consumption
The product does not properly control the allocation and maintenance of a limited resource, thereby enabling an actor to influence the amount of resources consumed, eventually leading to the exhaustion of available resources.
Repository: https://gitlab.com/libtiff/libtiff
Files changed:
contrib/addtiffo/tif_overview.c
tools/tiff2pdf.c
tools/tiffcrop.c
Commit message: Fix for bug 2772

It is possible to craft a TIFF document where the IFD list is circular,
leading to an infinite loop while traversing the chain. The libtiff
directory reader has a failsafe that will break out of this loop after
reading 65535 directory entries, but it will continue processing,
consuming time and resources to process what is essentially a bogus TIFF
document.

This change fixes the above behavior by breaking out of processing when
a TIFF document has >= 65535 directories and terminating with an error.


Vulnerable code:
    TIFFSetDirectory( hTIFF, (tdir_t) (TIFFNumberOfDirectories(hTIFF)-1) );
  /* read multiple input files and write to output file(s) */
    total_images = TIFFNumberOfDirectories(in); 

Fixed code:
#define TIFF_DIR_MAX  65534

    tdir_t	iNumDir;
    iNumDir = TIFFNumberOfDirectories(hTIFF);
    if( iNumDir > TIFF_DIR_MAX )
    {
        TIFFErrorExt( TIFFClientdata(hTIFF),
                      "TIFF_WriteOverview",
                      "File `%s' has too many directories.\n",
                      TIFFFileName(hTIFF) );
        exit(-1);
    }
    TIFFSetDirectory( hTIFF, (tdir_t) (iNumDir - 1) );
#define TIFF_DIR_MAX    65534

	if(directorycount > TIFF_DIR_MAX) {
		TIFFError(
			TIFF2PDF_MODULE,
			"TIFF contains too many directories, %s",
			TIFFFileName(input));
		t2p->t2p_error = T2P_ERR_ERROR;
		return;
	}
#define TIFF_DIR_MAX  65534

  /* Read multiple input files and write to output file(s) */
    total_images = TIFFNumberOfDirectories(in);
    if (total_images > TIFF_DIR_MAX)
      {
      TIFFError (TIFFFileName(in), "File contains too many directories");
      if (out != NULL)
        (void) TIFFClose(out);
      return (1);
      }
CVE-2018-8905 (C, published 2018-03-22T04:29Z)
Description: value: In LibTIFF 4.0.9, a heap-based buffer overflow occurs in the function LZWDecodeCompat in tif_lzw.c via a crafted TIFF file, as demonstrated by tiff2ps.
Severity: MEDIUM (CVSS v3 base score: 8.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://gitlab.com/libtiff/libtiff
Files changed:
libtiff/tif_lzw.c
Commit message: LZWDecodeCompat(): fix potential index-out-of-bounds write. Fixes http://bugzilla.maptools.org/show_bug.cgi?id=2780 / CVE-2018-8905

The fix consists in using the similar code LZWDecode() to validate we
don't write outside of the output buffer.


Vulnerable code:
			assert(occ >= codep->length);
			op += codep->length;
			occ -= codep->length;
			tp = op;
				*--tp = codep->value;
			} while( (codep = codep->next) != NULL );

Fixed code:
	int len;
			len = codep->length;
			tp = op + len;
				int t;
				--tp;
				t = codep->value;
				codep = codep->next;
				*tp = (char)t;
			} while (codep && tp > op);
			assert(occ >= len);
			op += len;
			occ -= len;
CVE-2019-17546 (C, published 2019-10-14T02:15Z)
Description: value: tif_getimage.c in LibTIFF through 4.0.10, as used in GDAL through 3.0.1 and other products, has an integer overflow that potentially causes a heap-based buffer overflow via a crafted RGBA image, related to a "Negative-size-param" condition.
Severity: MEDIUM (CVSS v3 base score: 8.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://gitlab.com/libtiff/libtiff
Files changed:
libtiff/tif_getimage.c
Commit message: RGBA interface: fix integer overflow potentially causing write heap buffer overflow, especially on 32 bit builds. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=16443. Credit to OSS Fuzz


Vulnerable code:
		    ((row + img->row_offset)%rowsperstrip + nrowsub) * scanline)==(tmsize_t)(-1)
                            ((row + img->row_offset)%rowsperstrip + nrow) * scanline)==(tmsize_t)(-1)
		    p0, ((row + img->row_offset)%rowsperstrip + nrow) * scanline)==(tmsize_t)(-1)
                                            p1, ((row + img->row_offset)%rowsperstrip + nrow) * scanline) == (tmsize_t)(-1)
                                            p2, ((row + img->row_offset)%rowsperstrip + nrow) * scanline) == (tmsize_t)(-1)
			    pa, ((row + img->row_offset)%rowsperstrip + nrow) * scanline)==(tmsize_t)(-1)

Fixed code:
		uint32 temp;
		temp = (row + img->row_offset)%rowsperstrip + nrowsub;
		if( scanline > 0 && temp > (size_t)(TIFF_TMSIZE_T_MAX / scanline) )
		{
			TIFFErrorExt(tif->tif_clientdata, TIFFFileName(tif), "Integer overflow in gtStripContig");
			return 0;
		}
		    temp * scanline)==(tmsize_t)(-1)
                uint32 temp;
                temp = (row + img->row_offset)%rowsperstrip + nrow;
                if( scanline > 0 && temp > (size_t)(TIFF_TMSIZE_T_MAX / scanline) )
                {
                        TIFFErrorExt(tif->tif_clientdata, TIFFFileName(tif), "Integer overflow in gtStripSeparate");
                        return 0;
                }
                            temp * scanline)==(tmsize_t)(-1)
		    p0, temp * scanline)==(tmsize_t)(-1)
                                            p1, temp * scanline) == (tmsize_t)(-1)
                                            p2, temp * scanline) == (tmsize_t)(-1)
			    pa, temp * scanline)==(tmsize_t)(-1)
CVE-2019-17546 (C, published 2019-10-14T02:15Z)
Description: value: tif_getimage.c in LibTIFF through 4.0.10, as used in GDAL through 3.0.1 and other products, has an integer overflow that potentially causes a heap-based buffer overflow via a crafted RGBA image, related to a "Negative-size-param" condition.
Severity: MEDIUM (CVSS v3 base score: 8.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://gitlab.com/libtiff/libtiff
Files changed:
libtiff/tif_getimage.c
Commit message: RGBA interface: fix integer overflow potentially causing write heap buffer overflow, especially on 32 bit builds. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=16443. Credit to OSS Fuzz


Vulnerable code:
		    ((row + img->row_offset)%rowsperstrip + nrowsub) * scanline)==(tmsize_t)(-1)
                            ((row + img->row_offset)%rowsperstrip + nrow) * scanline)==(tmsize_t)(-1)
		    p0, ((row + img->row_offset)%rowsperstrip + nrow) * scanline)==(tmsize_t)(-1)
                                            p1, ((row + img->row_offset)%rowsperstrip + nrow) * scanline) == (tmsize_t)(-1)
                                            p2, ((row + img->row_offset)%rowsperstrip + nrow) * scanline) == (tmsize_t)(-1)
			    pa, ((row + img->row_offset)%rowsperstrip + nrow) * scanline)==(tmsize_t)(-1)

Fixed code:
		uint32 temp;
		temp = (row + img->row_offset)%rowsperstrip + nrowsub;
		if( scanline > 0 && temp > (size_t)(TIFF_TMSIZE_T_MAX / scanline) )
		{
			TIFFErrorExt(tif->tif_clientdata, TIFFFileName(tif), "Integer overflow in gtStripContig");
			return 0;
		}
		    temp * scanline)==(tmsize_t)(-1)
                uint32 temp;
                temp = (row + img->row_offset)%rowsperstrip + nrow;
                if( scanline > 0 && temp > (size_t)(TIFF_TMSIZE_T_MAX / scanline) )
                {
                        TIFFErrorExt(tif->tif_clientdata, TIFFFileName(tif), "Integer overflow in gtStripSeparate");
                        return 0;
                }
                            temp * scanline)==(tmsize_t)(-1)
		    p0, temp * scanline)==(tmsize_t)(-1)
                                            p1, temp * scanline) == (tmsize_t)(-1)
                                            p2, temp * scanline) == (tmsize_t)(-1)
			    pa, temp * scanline)==(tmsize_t)(-1)