Req #79269 [NEW]: Bundled SQLite is compiled without SQLITE_MAX_VARIABLE_NUMBER

From: Date: Thu, 13 Feb 2020 00:28:03 +0000
Subject: Req #79269 [NEW]: Bundled SQLite is compiled without SQLITE_MAX_VARIABLE_NUMBER
Groups: php.bugs 
Request: Send a blank email to php-bugs+get-225545@lists.php.net to get a copy of this message
From: effulgentsia1 at gmail dot com Operating system: All PHP version: 7.3.14 Package: PDO SQLite Bug Type: Feature/Change Request Bug description:Bundled SQLite is compiled without SQLITE_MAX_VARIABLE_NUMBER Description: ------------ PHP 7.4 unbundled the SQLite library, so benefits from how it was compiled on the system. Many systems (Mac OSX, Debian, Ubuntu, and others) compile it with SQLITE_MAX_VARIABLE_NUMBER=250000 or larger (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717900). PHP 7.3 doesn't specify the flag (https://github.com/php/php-src/blob/PHP-7.3/ext/sqlite3/config0.m4#L80), so gets the low default of 999 (https://www.sqlite.org/limits.html#max_variable_number). It would be helpful if PHP 7.3 could match the Debian number, to make the test script work. SQLite sets the default so low in order to prevent SQL injection attacks from allocating excessive memory on low memory embedded systems (https://www.mail-archive.com/sqlite-users@mailinglists.sqlite.org/msg119067.html). However, I don't think PHP is used on such systems, and a SQL injection attack in a PHP application can already do far more harm than merely allocating 18MB of memory (72 bytes * 250000). I also filed a similar issue for Fedora (https://bugzilla.redhat.com/show_bug.cgi?id=1798134). Test script: --------------- $large_array = range(0, 1000); $db = new PDO('sqlite::memory:'); $placeholders = implode(', ', array_fill(0, count($large_array), '?')); $stmt = $db->prepare("SELECT 1 WHERE 42 IN ($placeholders)"); var_dump($stmt->execute($large_array)); Expected result: ---------------- It should output "bool(true)", indicating that the execute() statement executed. Actual result: -------------- It outputs nothing, because the execute() statement passes more arguments than the 999 limit. -- Edit bug report at https://bugs.php.net/bug.php?id=79269&edit=1 -- Fix committed: https://bugs.php.net/fix.php?id=79269&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=79269&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=79269&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=79269&r=needscript Try newer version: https://bugs.php.net/fix.php?id=79269&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=79269&r=support Expected behavior: https://bugs.php.net/fix.php?id=79269&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=79269&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=79269&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=79269&r=globals PHP version support discontinued: https://bugs.php.net/fix.php?id=79269&r=phptooold Daylight Savings: https://bugs.php.net/fix.php?id=79269&r=dst IIS Stability: https://bugs.php.net/fix.php?id=79269&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=79269&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=79269&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=79269&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=79269&r=mysqlcfg

« previous php.bugs (#225545) next »