<story><title>Stranger Strings: An exploitable flaw in SQLite</title><url>https://blog.trailofbits.com/2022/10/25/sqlite-vulnerability-july-2022-library-api/</url></story><parent_chain></parent_chain><comment><author>gregors</author><text>Great work!!!&lt;p&gt;&amp;quot;SQLite is extensively tested with 100% branch test coverage. We discovered this vulnerability despite the tests, which raises the question: how did the tests miss it?&amp;quot;&lt;p&gt;Tests only validate known behavior. They didn&amp;#x27;t have a test that exercised a large string. I don&amp;#x27;t know how their test suite works but I&amp;#x27;m curious if quickcheck might have possibly found this or if the 32-bit viewpoint of the programmer at the time would have also limited possible generated values?</text></comment>
<story><title>Stranger Strings: An exploitable flaw in SQLite</title><url>https://blog.trailofbits.com/2022/10/25/sqlite-vulnerability-july-2022-library-api/</url></story><parent_chain></parent_chain><comment><author>harryvederci</author><text>&amp;quot;This bug is an array-bounds overflow. The bug is only accessible when using some of the C-language APIs provided by SQLite. The bug cannot be reached using SQL nor can it be reached by providing SQLite with a corrupt database file. The bug only comes up when very long string inputs (greater than 2 billion bytes in length) are provided as arguments to a few specific C-language interfaces, and even then only under special circumstances.&amp;quot;&lt;p&gt;Source: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.sqlite.org&amp;#x2F;cves.html#status_of_recent_sqlite_cves&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.sqlite.org&amp;#x2F;cves.html#status_of_recent_sqlite_cve...&lt;/a&gt;</text></comment>