summaryrefslogtreecommitdiffstats
path: root/bug69975.patch
diff options
context:
space:
mode:
authorRemi Collet <fedora@famillecollet.com>2016-07-22 19:29:20 +0200
committerRemi Collet <fedora@famillecollet.com>2016-07-22 19:29:20 +0200
commit2f649ee4cbea50aaf88ae480ecfe36651dd135a2 (patch)
treea354b0289ff36de74a82652f9946413b6917dd95 /bug69975.patch
parentd3a4c0e1202c51c100fe28a60ed9beab1918de91 (diff)
PHP 5.4.45 with security fix from 5.5.38
Diffstat (limited to 'bug69975.patch')
-rw-r--r--bug69975.patch89
1 files changed, 89 insertions, 0 deletions
diff --git a/bug69975.patch b/bug69975.patch
new file mode 100644
index 0000000..4aafb17
--- /dev/null
+++ b/bug69975.patch
@@ -0,0 +1,89 @@
+Adapted for 5.4, by Remi Collet, from:
+
+
+From 82637e818776d4fe778fb1dbac26eeece02e900c Mon Sep 17 00:00:00 2001
+From: "Christoph M. Becker" <cmb@php.net>
+Date: Fri, 3 Jul 2015 00:04:50 +0200
+Subject: [PATCH] Fix #69975: PHP segfaults when accessing nvarchar(max)
+ defined columns
+
+The SQL Server Native Client 11.0 and maybe other ODBC drivers report
+NVARCHAR(MAX) columns as SQL_WVARCHAR with size 0. This causes too small a
+buffer to be emalloc'd, likely causing a segfault in the following. As we don't
+know the real size of the column data, we treat such colums as
+SQL_WLONGVARCHAR.
+
+The related bug #67437 suggests that some drivers report a size of ~4GB. It is
+not certain that this is really the case (there might be some integer overflow
+involved, and anyway, there has been no feedback), so we do not cater for this
+now. However, it would not be hard to treat all sizes above a certain threshold
+in a similar way, i.e. as SQL_WLONGVARCHAR.
+
+(cherry picked from commit 16db4d1462bf3eacb93c0cd940f799160a284b24)
+(cherry picked from commit 344ff5dd4c538eaebea075f7705321f8b86d0b47)
+---
+ ext/odbc/php_odbc.c | 7 +++++++
+ ext/odbc/tests/bug69975.phpt | 32 ++++++++++++++++++++++++++++++++
+ 2 files changed, 39 insertions(+)
+ create mode 100644 ext/odbc/tests/bug69975.phpt
+
+diff --git a/ext/odbc/php_odbc.c b/ext/odbc/php_odbc.c
+index ddfbc4e..1d70b7f 100644
+--- a/ext/odbc/php_odbc.c
++++ b/ext/odbc/php_odbc.c
+@@ -1005,6 +1005,14 @@ int odbc_bindcols(odbc_result *result TS
+ default:
+ rc = SQLColAttributes(result->stmt, (SQLUSMALLINT)(i+1), colfieldid,
+ NULL, 0, NULL, &displaysize);
++#if defined(ODBCVER) && (ODBCVER >= 0x0300)
++ /* Workaround for drivers that report NVARCHAR(MAX) columns as SQL_WVARCHAR with size 0 (bug #69975) */
++ if (result->values[i].coltype == SQL_WVARCHAR && displaysize == 0) {
++ result->values[i].coltype = SQL_WLONGVARCHAR;
++ result->values[i].value = NULL;
++ break;
++ }
++#endif
+ /* Workaround for Oracle ODBC Driver bug (#50162) when fetching TIMESTAMP column */
+ if (result->values[i].coltype == SQL_TIMESTAMP) {
+ displaysize += 3;
+diff --git a/ext/odbc/tests/bug69975.phpt b/ext/odbc/tests/bug69975.phpt
+new file mode 100644
+index 0000000..eca7564
+--- /dev/null
++++ b/ext/odbc/tests/bug69975.phpt
+@@ -0,0 +1,32 @@
++--TEST--
++Bug #69975 (PHP segfaults when accessing nvarchar(max) defined columns)
++--SKIPIF--
++<?php include 'skipif.inc'; ?>
++--FILE--
++<?php
++include 'config.inc';
++
++$conn = odbc_connect($dsn, $user, $pass);
++@odbc_exec($conn, 'CREATE DATABASE odbcTEST');
++odbc_exec($conn, 'CREATE TABLE FOO (ID INT, VARCHAR_COL NVARCHAR(MAX))');
++odbc_exec($conn, "INSERT INTO FOO VALUES (1, 'foo')");
++
++$result = odbc_exec($conn, "SELECT VARCHAR_COL FROM FOO");
++var_dump(odbc_fetch_array($result));
++
++echo "ready";
++?>
++--EXPECT--
++array(1) {
++ ["VARCHAR_COL"]=>
++ string(3) "foo"
++}
++ready
++--CLEAN--
++<?php
++include 'config.inc';
++
++$conn = odbc_connect($dsn, $user, $pass);
++odbc_exec($conn, 'DROP TABLE FOO');
++odbc_exec($conn, 'DROP DATABASE odbcTEST');
++?>
+--
+2.1.4
+