[clang static analyzer] false negative related to alpha.security.ArrayBoundV2

[0x21af]

For this case, If l_2003[9][0] is accessed, the analyzer would report "Out of bound memory access". However, when accessing l_2003[9][0].a, it doesn't.

struct S1 {
    unsigned a : 2
} b() {
    struct S1 l_2003[5][4] = {};
    l_2003[9][0].a;
}
int main() { b(); }

See it live: https://godbolt.org/z/cxYYv6vMv

Could you take a look when you have time? Many thanks!

[llvmbot]

@llvm/issue-subscribers-clang-static-analyzer

Author: ML.M (hallo-mars)

For this case, If `l_2003[9][0]` is accessed, the analyzer would report "Out of bound memory access". However, when accessing `l_2003[9][0].a`, it doesn't.

struct S1 {
    unsigned a : 2
} b() {
    struct S1 l_2003[5][4] = {};
    l_2003[9][0].a;
}
int main() { b(); }

See it live: https://godbolt.org/z/cxYYv6vMv

Could you take a look when you have time? Many thanks!

[NagyDonat]

I'm gradually rewriting this checker to fix its various limitations, and this issue is already on my TODO list. After merging my current improvements, the next step could be a commit that fixes this.

This issue is caused by the fact that the checker looks for memory access operations (checkLocation() callback) that access an ElementRegion, but an expression like array[index].field implies an access to a FieldRegion (which happens to be a sub-region of an ElementRegion, but the checker doesn't investigate that). Note that when accessing nested sub-regions (like array[index].field) the analyzer engine only calls the checkLocation() callback for the innermost accessed region.

It'd be possible to fix this "directly" by looking for ElementRegion layers in the middle of the stack of nested sub-regions (e.g. array[index].field is a FieldRegion, but its parent is an ElementRegion, so we perform bounds checking for it). However, my plan is that I'll switch from the abstract checkLocation() callback to callbacks that observe the concrete array subscript operators (and pointer dereference to handle things like *(array + index)), because this would also let me improve the quality of the messages.

[0x21af]

I'm gradually rewriting this checker to fix its various limitations, and this issue is already on my TODO list. After merging my current improvements, the next step could be a commit that fixes this.

This issue is caused by the fact that the checker looks for memory access operations (checkLocation() callback) that access an ElementRegion, but an expression like array[index].field implies an access to a FieldRegion (which happens to be a sub-region of an ElementRegion, but the checker doesn't investigate that). Note that when accessing nested sub-regions (like array[index].field) the analyzer engine only calls the checkLocation() callback for the innermost accessed region.

It'd be possible to fix this "directly" by looking for ElementRegion layers in the middle of the stack of nested sub-regions (e.g. array[index].field is a FieldRegion, but its parent is an ElementRegion, so we perform bounds checking for it). However, my plan is that I'll switch from the abstract checkLocation() callback to callbacks that observe the concrete array subscript operators (and pointer dereference to handle things like *(array + index)), because this would also let me improve the quality of the messages.

Thanks for your comprehensive explanation of the issue.

I deeply appreciate the efforts you've made to enhance the quality of the checker. Looking forward to the updates :)