|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
[2022-10-29 13:26 UTC] cmb@php.net
-Assigned To:
+Assigned To: cmb
[2022-10-29 14:09 UTC] cmb@php.net
[2022-10-31 16:24 UTC] cmb@php.net
-Assigned To: cmb
+Assigned To: stas
[2022-10-31 16:24 UTC] cmb@php.net
[2022-12-19 06:22 UTC] stas@php.net
-CVE-ID:
+CVE-ID: 2022-31631
[2022-12-19 06:27 UTC] git@php.net
[2022-12-19 06:27 UTC] git@php.net
-Status: Assigned
+Status: Closed
|
|||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Mon Nov 03 07:00:01 2025 UTC |
Description: ------------ Due to an uncaught integer overflow, PDO::quote() of PDO_SQLite may return a not properly quoted string. The exact details likely depend on the implementation of sqlite3_snprintf(), but with recent versions (tested sqlite 3.39.2 and sqlite 3.39.4) it is possible to force the function to return a single apostrophe, if the function is called on user supplied input without any length restrictions in place (common memory_limit settings should prevent that though, and usually also post_max_size etc.) The problem is that the length parameter of sqlite3_snprintf() is of type int, but we're passing an unrestricted zend_long value, so overflow may occur. This renders the previous safe_emalloc() practically useless, since it only prevents overflow of size_t values. For 32bit architecture (where we assume sizeof(zend_long) == sizeof(int)) this is not a problem, but for 64bit architectures it is, as the given test script demonstrates. Test script: --------------- <?php $pdo = new PDO("sqlite::memory:"); $string = str_repeat("a", 0x80000000); var_dump($pdo->quote($string)); ?> Expected result: ---------------- A properly quoted string, false, or some other error indication. Actual result: -------------- string(1) "'"