A local copy of OpenSSL from GitHub
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

784 lines
21 KiB

Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
23 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
Fix memory issues in BIO_*printf functions The internal |fmtstr| function used in processing a "%s" format string in the BIO_*printf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings. Additionally the internal |doapr_outch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INT_MAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur. These issues will only occur on certain platforms where sizeof(size_t) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIO_*printf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments. Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. CVE-2016-0799 Issue reported by Guido Vranken. Reviewed-by: Andy Polyakov <appro@openssl.org>
7 years ago
  1. /*
  2. * Copyright 1995-2016 The OpenSSL Project Authors. All Rights Reserved.
  3. *
  4. * Licensed under the OpenSSL license (the "License"). You may not use
  5. * this file except in compliance with the License. You can obtain a copy
  6. * in the file LICENSE in the source distribution or at
  7. * https://www.openssl.org/source/license.html
  8. */
  9. #include <stdio.h>
  10. #include <string.h>
  11. #include <ctype.h>
  12. #include <assert.h>
  13. #include <limits.h>
  14. #include "internal/cryptlib.h"
  15. #ifndef NO_SYS_TYPES_H
  16. # include <sys/types.h>
  17. #endif
  18. #include <openssl/bn.h> /* To get BN_LLONG properly defined */
  19. #include <openssl/bio.h>
  20. #if defined(BN_LLONG) || defined(SIXTY_FOUR_BIT)
  21. # ifndef HAVE_LONG_LONG
  22. # define HAVE_LONG_LONG 1
  23. # endif
  24. #endif
  25. /*
  26. * Copyright Patrick Powell 1995
  27. * This code is based on code written by Patrick Powell <papowell@astart.com>
  28. * It may be used for any purpose as long as this notice remains intact
  29. * on all source code distributions.
  30. */
  31. #ifdef HAVE_LONG_DOUBLE
  32. # define LDOUBLE long double
  33. #else
  34. # define LDOUBLE double
  35. #endif
  36. #ifdef HAVE_LONG_LONG
  37. # if defined(_WIN32) && !defined(__GNUC__)
  38. # define LLONG __int64
  39. # else
  40. # define LLONG long long
  41. # endif
  42. #else
  43. # define LLONG long
  44. #endif
  45. static int fmtstr(char **, char **, size_t *, size_t *,
  46. const char *, int, int, int);
  47. static int fmtint(char **, char **, size_t *, size_t *,
  48. LLONG, int, int, int, int);
  49. static int fmtfp(char **, char **, size_t *, size_t *,
  50. LDOUBLE, int, int, int);
  51. static int doapr_outch(char **, char **, size_t *, size_t *, int);
  52. static int _dopr(char **sbuffer, char **buffer,
  53. size_t *maxlen, size_t *retlen, int *truncated,
  54. const char *format, va_list args);
  55. /* format read states */
  56. #define DP_S_DEFAULT 0
  57. #define DP_S_FLAGS 1
  58. #define DP_S_MIN 2
  59. #define DP_S_DOT 3
  60. #define DP_S_MAX 4
  61. #define DP_S_MOD 5
  62. #define DP_S_CONV 6
  63. #define DP_S_DONE 7
  64. /* format flags - Bits */
  65. #define DP_F_MINUS (1 << 0)
  66. #define DP_F_PLUS (1 << 1)
  67. #define DP_F_SPACE (1 << 2)
  68. #define DP_F_NUM (1 << 3)
  69. #define DP_F_ZERO (1 << 4)
  70. #define DP_F_UP (1 << 5)
  71. #define DP_F_UNSIGNED (1 << 6)
  72. /* conversion flags */
  73. #define DP_C_SHORT 1
  74. #define DP_C_LONG 2
  75. #define DP_C_LDOUBLE 3
  76. #define DP_C_LLONG 4
  77. /* some handy macros */
  78. #define char_to_int(p) (p - '0')
  79. #define OSSL_MAX(p,q) ((p >= q) ? p : q)
  80. static int
  81. _dopr(char **sbuffer,
  82. char **buffer,
  83. size_t *maxlen,
  84. size_t *retlen, int *truncated, const char *format, va_list args)
  85. {
  86. char ch;
  87. LLONG value;
  88. LDOUBLE fvalue;
  89. char *strvalue;
  90. int min;
  91. int max;
  92. int state;
  93. int flags;
  94. int cflags;
  95. size_t currlen;
  96. state = DP_S_DEFAULT;
  97. flags = currlen = cflags = min = 0;
  98. max = -1;
  99. ch = *format++;
  100. while (state != DP_S_DONE) {
  101. if (ch == '\0' || (buffer == NULL && currlen >= *maxlen))
  102. state = DP_S_DONE;
  103. switch (state) {
  104. case DP_S_DEFAULT:
  105. if (ch == '%')
  106. state = DP_S_FLAGS;
  107. else
  108. if(!doapr_outch(sbuffer, buffer, &currlen, maxlen, ch))
  109. return 0;
  110. ch = *format++;
  111. break;
  112. case DP_S_FLAGS:
  113. switch (ch) {
  114. case '-':
  115. flags |= DP_F_MINUS;
  116. ch = *format++;
  117. break;
  118. case '+':
  119. flags |= DP_F_PLUS;
  120. ch = *format++;
  121. break;
  122. case ' ':
  123. flags |= DP_F_SPACE;
  124. ch = *format++;
  125. break;
  126. case '#':
  127. flags |= DP_F_NUM;
  128. ch = *format++;
  129. break;
  130. case '0':
  131. flags |= DP_F_ZERO;
  132. ch = *format++;
  133. break;
  134. default:
  135. state = DP_S_MIN;
  136. break;
  137. }
  138. break;
  139. case DP_S_MIN:
  140. if (isdigit((unsigned char)ch)) {
  141. min = 10 * min + char_to_int(ch);
  142. ch = *format++;
  143. } else if (ch == '*') {
  144. min = va_arg(args, int);
  145. ch = *format++;
  146. state = DP_S_DOT;
  147. } else
  148. state = DP_S_DOT;
  149. break;
  150. case DP_S_DOT:
  151. if (ch == '.') {
  152. state = DP_S_MAX;
  153. ch = *format++;
  154. } else
  155. state = DP_S_MOD;
  156. break;
  157. case DP_S_MAX:
  158. if (isdigit((unsigned char)ch)) {
  159. if (max < 0)
  160. max = 0;
  161. max = 10 * max + char_to_int(ch);
  162. ch = *format++;
  163. } else if (ch == '*') {
  164. max = va_arg(args, int);
  165. ch = *format++;
  166. state = DP_S_MOD;
  167. } else
  168. state = DP_S_MOD;
  169. break;
  170. case DP_S_MOD:
  171. switch (ch) {
  172. case 'h':
  173. cflags = DP_C_SHORT;
  174. ch = *format++;
  175. break;
  176. case 'l':
  177. if (*format == 'l') {
  178. cflags = DP_C_LLONG;
  179. format++;
  180. } else
  181. cflags = DP_C_LONG;
  182. ch = *format++;
  183. break;
  184. case 'q':
  185. cflags = DP_C_LLONG;
  186. ch = *format++;
  187. break;
  188. case 'L':
  189. cflags = DP_C_LDOUBLE;
  190. ch = *format++;
  191. break;
  192. default:
  193. break;
  194. }
  195. state = DP_S_CONV;
  196. break;
  197. case DP_S_CONV:
  198. switch (ch) {
  199. case 'd':
  200. case 'i':
  201. switch (cflags) {
  202. case DP_C_SHORT:
  203. value = (short int)va_arg(args, int);
  204. break;
  205. case DP_C_LONG:
  206. value = va_arg(args, long int);
  207. break;
  208. case DP_C_LLONG:
  209. value = va_arg(args, LLONG);
  210. break;
  211. default:
  212. value = va_arg(args, int);
  213. break;
  214. }
  215. if (!fmtint(sbuffer, buffer, &currlen, maxlen, value, 10, min,
  216. max, flags))
  217. return 0;
  218. break;
  219. case 'X':
  220. flags |= DP_F_UP;
  221. /* FALLTHROUGH */
  222. case 'x':
  223. case 'o':
  224. case 'u':
  225. flags |= DP_F_UNSIGNED;
  226. switch (cflags) {
  227. case DP_C_SHORT:
  228. value = (unsigned short int)va_arg(args, unsigned int);
  229. break;
  230. case DP_C_LONG:
  231. value = (LLONG) va_arg(args, unsigned long int);
  232. break;
  233. case DP_C_LLONG:
  234. value = va_arg(args, unsigned LLONG);
  235. break;
  236. default:
  237. value = (LLONG) va_arg(args, unsigned int);
  238. break;
  239. }
  240. if (!fmtint(sbuffer, buffer, &currlen, maxlen, value,
  241. ch == 'o' ? 8 : (ch == 'u' ? 10 : 16),
  242. min, max, flags))
  243. return 0;
  244. break;
  245. case 'f':
  246. if (cflags == DP_C_LDOUBLE)
  247. fvalue = va_arg(args, LDOUBLE);
  248. else
  249. fvalue = va_arg(args, double);
  250. if (!fmtfp(sbuffer, buffer, &currlen, maxlen, fvalue, min, max,
  251. flags))
  252. return 0;
  253. break;
  254. case 'E':
  255. flags |= DP_F_UP;
  256. case 'e':
  257. if (cflags == DP_C_LDOUBLE)
  258. fvalue = va_arg(args, LDOUBLE);
  259. else
  260. fvalue = va_arg(args, double);
  261. break;
  262. case 'G':
  263. flags |= DP_F_UP;
  264. case 'g':
  265. if (cflags == DP_C_LDOUBLE)
  266. fvalue = va_arg(args, LDOUBLE);
  267. else
  268. fvalue = va_arg(args, double);
  269. break;
  270. case 'c':
  271. if(!doapr_outch(sbuffer, buffer, &currlen, maxlen,
  272. va_arg(args, int)))
  273. return 0;
  274. break;
  275. case 's':
  276. strvalue = va_arg(args, char *);
  277. if (max < 0) {
  278. if (buffer)
  279. max = INT_MAX;
  280. else
  281. max = *maxlen;
  282. }
  283. if (!fmtstr(sbuffer, buffer, &currlen, maxlen, strvalue,
  284. flags, min, max))
  285. return 0;
  286. break;
  287. case 'p':
  288. value = (size_t)va_arg(args, void *);
  289. if (!fmtint(sbuffer, buffer, &currlen, maxlen,
  290. value, 16, min, max, flags | DP_F_NUM))
  291. return 0;
  292. break;
  293. case 'n': /* XXX */
  294. if (cflags == DP_C_SHORT) {
  295. short int *num;
  296. num = va_arg(args, short int *);
  297. *num = currlen;
  298. } else if (cflags == DP_C_LONG) { /* XXX */
  299. long int *num;
  300. num = va_arg(args, long int *);
  301. *num = (long int)currlen;
  302. } else if (cflags == DP_C_LLONG) { /* XXX */
  303. LLONG *num;
  304. num = va_arg(args, LLONG *);
  305. *num = (LLONG) currlen;
  306. } else {
  307. int *num;
  308. num = va_arg(args, int *);
  309. *num = currlen;
  310. }
  311. break;
  312. case '%':
  313. if(!doapr_outch(sbuffer, buffer, &currlen, maxlen, ch))
  314. return 0;
  315. break;
  316. case 'w':
  317. /* not supported yet, treat as next char */
  318. ch = *format++;
  319. break;
  320. default:
  321. /* unknown, skip */
  322. break;
  323. }
  324. ch = *format++;
  325. state = DP_S_DEFAULT;
  326. flags = cflags = min = 0;
  327. max = -1;
  328. break;
  329. case DP_S_DONE:
  330. break;
  331. default:
  332. break;
  333. }
  334. }
  335. *truncated = (currlen > *maxlen - 1);
  336. if (*truncated)
  337. currlen = *maxlen - 1;
  338. if(!doapr_outch(sbuffer, buffer, &currlen, maxlen, '\0'))
  339. return 0;
  340. *retlen = currlen - 1;
  341. return 1;
  342. }
  343. static int
  344. fmtstr(char **sbuffer,
  345. char **buffer,
  346. size_t *currlen,
  347. size_t *maxlen, const char *value, int flags, int min, int max)
  348. {
  349. int padlen;
  350. size_t strln;
  351. int cnt = 0;
  352. if (value == 0)
  353. value = "<NULL>";
  354. strln = strlen(value);
  355. if (strln > INT_MAX)
  356. strln = INT_MAX;
  357. padlen = min - strln;
  358. if (min < 0 || padlen < 0)
  359. padlen = 0;
  360. if (flags & DP_F_MINUS)
  361. padlen = -padlen;
  362. while ((padlen > 0) && (cnt < max)) {
  363. if(!doapr_outch(sbuffer, buffer, currlen, maxlen, ' '))
  364. return 0;
  365. --padlen;
  366. ++cnt;
  367. }
  368. while (*value && (cnt < max)) {
  369. if(!doapr_outch(sbuffer, buffer, currlen, maxlen, *value++))
  370. return 0;
  371. ++cnt;
  372. }
  373. while ((padlen < 0) && (cnt < max)) {
  374. if(!doapr_outch(sbuffer, buffer, currlen, maxlen, ' '))
  375. return 0;
  376. ++padlen;
  377. ++cnt;
  378. }
  379. return 1;
  380. }
  381. static int
  382. fmtint(char **sbuffer,
  383. char **buffer,
  384. size_t *currlen,
  385. size_t *maxlen, LLONG value, int base, int min, int max, int flags)
  386. {
  387. int signvalue = 0;
  388. const char *prefix = "";
  389. unsigned LLONG uvalue;
  390. char convert[DECIMAL_SIZE(value) + 3];
  391. int place = 0;
  392. int spadlen = 0;
  393. int zpadlen = 0;
  394. int caps = 0;
  395. if (max < 0)
  396. max = 0;
  397. uvalue = value;
  398. if (!(flags & DP_F_UNSIGNED)) {
  399. if (value < 0) {
  400. signvalue = '-';
  401. uvalue = -value;
  402. } else if (flags & DP_F_PLUS)
  403. signvalue = '+';
  404. else if (flags & DP_F_SPACE)
  405. signvalue = ' ';
  406. }
  407. if (flags & DP_F_NUM) {
  408. if (base == 8)
  409. prefix = "0";
  410. if (base == 16)
  411. prefix = "0x";
  412. }
  413. if (flags & DP_F_UP)
  414. caps = 1;
  415. do {
  416. convert[place++] = (caps ? "0123456789ABCDEF" : "0123456789abcdef")
  417. [uvalue % (unsigned)base];
  418. uvalue = (uvalue / (unsigned)base);
  419. } while (uvalue && (place < (int)sizeof(convert)));
  420. if (place == sizeof(convert))
  421. place--;
  422. convert[place] = 0;
  423. zpadlen = max - place;
  424. spadlen =
  425. min - OSSL_MAX(max, place) - (signvalue ? 1 : 0) - strlen(prefix);
  426. if (zpadlen < 0)
  427. zpadlen = 0;
  428. if (spadlen < 0)
  429. spadlen = 0;
  430. if (flags & DP_F_ZERO) {
  431. zpadlen = OSSL_MAX(zpadlen, spadlen);
  432. spadlen = 0;
  433. }
  434. if (flags & DP_F_MINUS)
  435. spadlen = -spadlen;
  436. /* spaces */
  437. while (spadlen > 0) {
  438. if(!doapr_outch(sbuffer, buffer, currlen, maxlen, ' '))
  439. return 0;
  440. --spadlen;
  441. }
  442. /* sign */
  443. if (signvalue)
  444. if(!doapr_outch(sbuffer, buffer, currlen, maxlen, signvalue))
  445. return 0;
  446. /* prefix */
  447. while (*prefix) {
  448. if(!doapr_outch(sbuffer, buffer, currlen, maxlen, *prefix))
  449. return 0;
  450. prefix++;
  451. }
  452. /* zeros */
  453. if (zpadlen > 0) {
  454. while (zpadlen > 0) {
  455. if(!doapr_outch(sbuffer, buffer, currlen, maxlen, '0'))
  456. return 0;
  457. --zpadlen;
  458. }
  459. }
  460. /* digits */
  461. while (place > 0) {
  462. if (!doapr_outch(sbuffer, buffer, currlen, maxlen, convert[--place]))
  463. return 0;
  464. }
  465. /* left justified spaces */
  466. while (spadlen < 0) {
  467. if (!doapr_outch(sbuffer, buffer, currlen, maxlen, ' '))
  468. return 0;
  469. ++spadlen;
  470. }
  471. return 1;
  472. }
  473. static LDOUBLE abs_val(LDOUBLE value)
  474. {
  475. LDOUBLE result = value;
  476. if (value < 0)
  477. result = -value;
  478. return result;
  479. }
  480. static LDOUBLE pow_10(int in_exp)
  481. {
  482. LDOUBLE result = 1;
  483. while (in_exp) {
  484. result *= 10;
  485. in_exp--;
  486. }
  487. return result;
  488. }
  489. static long roundv(LDOUBLE value)
  490. {
  491. long intpart;
  492. intpart = (long)value;
  493. value = value - intpart;
  494. if (value >= 0.5)
  495. intpart++;
  496. return intpart;
  497. }
  498. static int
  499. fmtfp(char **sbuffer,
  500. char **buffer,
  501. size_t *currlen,
  502. size_t *maxlen, LDOUBLE fvalue, int min, int max, int flags)
  503. {
  504. int signvalue = 0;
  505. LDOUBLE ufvalue;
  506. char iconvert[20];
  507. char fconvert[20];
  508. int iplace = 0;
  509. int fplace = 0;
  510. int padlen = 0;
  511. int zpadlen = 0;
  512. long intpart;
  513. long fracpart;
  514. long max10;
  515. if (max < 0)
  516. max = 6;
  517. ufvalue = abs_val(fvalue);
  518. if (fvalue < 0)
  519. signvalue = '-';
  520. else if (flags & DP_F_PLUS)
  521. signvalue = '+';
  522. else if (flags & DP_F_SPACE)
  523. signvalue = ' ';
  524. intpart = (long)ufvalue;
  525. /*
  526. * sorry, we only support 9 digits past the decimal because of our
  527. * conversion method
  528. */
  529. if (max > 9)
  530. max = 9;
  531. /*
  532. * we "cheat" by converting the fractional part to integer by multiplying
  533. * by a factor of 10
  534. */
  535. max10 = roundv(pow_10(max));
  536. fracpart = roundv(pow_10(max) * (ufvalue - intpart));
  537. if (fracpart >= max10) {
  538. intpart++;
  539. fracpart -= max10;
  540. }
  541. /* convert integer part */
  542. do {
  543. iconvert[iplace++] = "0123456789"[intpart % 10];
  544. intpart = (intpart / 10);
  545. } while (intpart && (iplace < (int)sizeof(iconvert)));
  546. if (iplace == sizeof iconvert)
  547. iplace--;
  548. iconvert[iplace] = 0;
  549. /* convert fractional part */
  550. do {
  551. fconvert[fplace++] = "0123456789"[fracpart % 10];
  552. fracpart = (fracpart / 10);
  553. } while (fplace < max);
  554. if (fplace == sizeof fconvert)
  555. fplace--;
  556. fconvert[fplace] = 0;
  557. /* -1 for decimal point, another -1 if we are printing a sign */
  558. padlen = min - iplace - max - 1 - ((signvalue) ? 1 : 0);
  559. zpadlen = max - fplace;
  560. if (zpadlen < 0)
  561. zpadlen = 0;
  562. if (padlen < 0)
  563. padlen = 0;
  564. if (flags & DP_F_MINUS)
  565. padlen = -padlen;
  566. if ((flags & DP_F_ZERO) && (padlen > 0)) {
  567. if (signvalue) {
  568. if (!doapr_outch(sbuffer, buffer, currlen, maxlen, signvalue))
  569. return 0;
  570. --padlen;
  571. signvalue = 0;
  572. }
  573. while (padlen > 0) {
  574. if (!doapr_outch(sbuffer, buffer, currlen, maxlen, '0'))
  575. return 0;
  576. --padlen;
  577. }
  578. }
  579. while (padlen > 0) {
  580. if (!doapr_outch(sbuffer, buffer, currlen, maxlen, ' '))
  581. return 0;
  582. --padlen;
  583. }
  584. if (signvalue && !doapr_outch(sbuffer, buffer, currlen, maxlen, signvalue))
  585. return 0;
  586. while (iplace > 0) {
  587. if (!doapr_outch(sbuffer, buffer, currlen, maxlen, iconvert[--iplace]))
  588. return 0;
  589. }
  590. /*
  591. * Decimal point. This should probably use locale to find the correct
  592. * char to print out.
  593. */
  594. if (max > 0 || (flags & DP_F_NUM)) {
  595. if (!doapr_outch(sbuffer, buffer, currlen, maxlen, '.'))
  596. return 0;
  597. while (fplace > 0) {
  598. if(!doapr_outch(sbuffer, buffer, currlen, maxlen,
  599. fconvert[--fplace]))
  600. return 0;
  601. }
  602. }
  603. while (zpadlen > 0) {
  604. if (!doapr_outch(sbuffer, buffer, currlen, maxlen, '0'))
  605. return 0;
  606. --zpadlen;
  607. }
  608. while (padlen < 0) {
  609. if (!doapr_outch(sbuffer, buffer, currlen, maxlen, ' '))
  610. return 0;
  611. ++padlen;
  612. }
  613. return 1;
  614. }
  615. #define BUFFER_INC 1024
  616. static int
  617. doapr_outch(char **sbuffer,
  618. char **buffer, size_t *currlen, size_t *maxlen, int c)
  619. {
  620. /* If we haven't at least one buffer, someone has doe a big booboo */
  621. assert(*sbuffer != NULL || buffer != NULL);
  622. /* |currlen| must always be <= |*maxlen| */
  623. assert(*currlen <= *maxlen);
  624. if (buffer && *currlen == *maxlen) {
  625. if (*maxlen > INT_MAX - BUFFER_INC)
  626. return 0;
  627. *maxlen += BUFFER_INC;
  628. if (*buffer == NULL) {
  629. *buffer = OPENSSL_malloc(*maxlen);
  630. if (*buffer == NULL)
  631. return 0;
  632. if (*currlen > 0) {
  633. assert(*sbuffer != NULL);
  634. memcpy(*buffer, *sbuffer, *currlen);
  635. }
  636. *sbuffer = NULL;
  637. } else {
  638. char *tmpbuf;
  639. tmpbuf = OPENSSL_realloc(*buffer, *maxlen);
  640. if (tmpbuf == NULL)
  641. return 0;
  642. *buffer = tmpbuf;
  643. }
  644. }
  645. if (*currlen < *maxlen) {
  646. if (*sbuffer)
  647. (*sbuffer)[(*currlen)++] = (char)c;
  648. else
  649. (*buffer)[(*currlen)++] = (char)c;
  650. }
  651. return 1;
  652. }
  653. /***************************************************************************/
  654. int BIO_printf(BIO *bio, const char *format, ...)
  655. {
  656. va_list args;
  657. int ret;
  658. va_start(args, format);
  659. ret = BIO_vprintf(bio, format, args);
  660. va_end(args);
  661. return (ret);
  662. }
  663. int BIO_vprintf(BIO *bio, const char *format, va_list args)
  664. {
  665. int ret;
  666. size_t retlen;
  667. char hugebuf[1024 * 2]; /* Was previously 10k, which is unreasonable
  668. * in small-stack environments, like threads
  669. * or DOS programs. */
  670. char *hugebufp = hugebuf;
  671. size_t hugebufsize = sizeof(hugebuf);
  672. char *dynbuf = NULL;
  673. int ignored;
  674. dynbuf = NULL;
  675. if (!_dopr(&hugebufp, &dynbuf, &hugebufsize, &retlen, &ignored, format,
  676. args)) {
  677. OPENSSL_free(dynbuf);
  678. return -1;
  679. }
  680. if (dynbuf) {
  681. ret = BIO_write(bio, dynbuf, (int)retlen);
  682. OPENSSL_free(dynbuf);
  683. } else {
  684. ret = BIO_write(bio, hugebuf, (int)retlen);
  685. }
  686. return (ret);
  687. }
  688. /*
  689. * As snprintf is not available everywhere, we provide our own
  690. * implementation. This function has nothing to do with BIOs, but it's
  691. * closely related to BIO_printf, and we need *some* name prefix ... (XXX the
  692. * function should be renamed, but to what?)
  693. */
  694. int BIO_snprintf(char *buf, size_t n, const char *format, ...)
  695. {
  696. va_list args;
  697. int ret;
  698. va_start(args, format);
  699. ret = BIO_vsnprintf(buf, n, format, args);
  700. va_end(args);
  701. return (ret);
  702. }
  703. int BIO_vsnprintf(char *buf, size_t n, const char *format, va_list args)
  704. {
  705. size_t retlen;
  706. int truncated;
  707. if(!_dopr(&buf, NULL, &n, &retlen, &truncated, format, args))
  708. return -1;
  709. if (truncated)
  710. /*
  711. * In case of truncation, return -1 like traditional snprintf.
  712. * (Current drafts for ISO/IEC 9899 say snprintf should return the
  713. * number of characters that would have been written, had the buffer
  714. * been large enough.)
  715. */
  716. return -1;
  717. else
  718. return (retlen <= INT_MAX) ? (int)retlen : -1;
  719. }