On 11/15/2016 08:53 PM, Nico Williams wrote:
Another one that I find difficult to analyze is a possible out-of-bounds
read in vdbeSorterCompareInt():
85712 static const u8 aLen[] = {0, 1, 2, 3, 4, 6, 8 };
85713 int i;
85714 res = 0;
85715 for(i=0; i<aLen[s1]; i++){
where s1 is not guaranteed to be less than 7:
85692 const u8 * const p1 = (const u8 * const)pKey1;
85693 const u8 * const p2 = (const u8 * const)pKey2;
85694 const int s1 = p1[1]; /* Left hand serial type */
85695 const int s2 = p2[1]; /* Right hand serial type */
85700 assert( (s1>0 && s1<7) || s1==8 || s1==9 );
85701 assert( (s2>0 && s2<7) || s2==8 || s2==9 );
85702
85703 if( s1>7 && s2>7 ){
85704 res = s1 - s2;
85705 }else{
85706 if( s1==s2 ){
At 85715 we know that (s1 <= 7 || s2 <= 7) && s1 == s2, and we also know
that either s1 or s2 can be 8 or 9, so aLen[s1] at 85715 could very well
have s1 > 6, which would read past the bounds of aLen[].
In both of these cases very detailed knowledge of the VDBE being handled
might show that these uninitialized reads do not happen. If so, I don't
have that knowledge.
I'll hold off on other reports for the time being.
Nico
if( s1>7 && s2>7 ){
res = s1 - s2;
}else{
if( s1==s2 ){
// Accesses to aLen as mentioned above
If s1 > 7 && s2 > 7 is false, then at least one of s1 and s2 is not
above 7. If they are equal, then neither s1 nor s2 is above 7.
> and we also know that either s1 or s2 can be 8 or 9,
This is false, unless I am mistaken. See my reasoning above.
The issue is valid, and the message your analyzer (or compiler) wrote is
correct: it is not guaranteed to be < 7, which it should be.
I am unsure whether or not this is actually a bug, but it almost
certainly is a mistake.
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
