Skip to content

[DRAFT] [inferbo] bounds-check array fields of local structs and objects - #2185

Draft
VladimirMakaev wants to merge 1 commit into
facebook:mainfrom
VladimirMakaev:inferbo-struct-array-fields
Draft

VladimirMakaev wants to merge 1 commit into
facebook:mainfrom
VladimirMakaev:inferbo-struct-array-fields

Conversation

@VladimirMakaev

@VladimirMakaev VladimirMakaev commented Oct 2, 2026 •

Copy link
Copy Markdown
Contributor

Inferbo declared no arrays for the array fields of local structs and C++ objects, so their
accesses went unchecked. Array fields passed to functions or models, as in g(s.arr) or
strcpy(p->name, src), evaluated to the field's cell instead of its array, also for heap and
parameter structs.

#include <string.h>

struct S {
  int arr[4];
  char name[8];
};

void f(void) {
  struct S s;
  s.arr[4] = 0; // Infer missed: buffer overrun
  strcpy(s.name, "12345678"); // Infer missed: buffer overrun
}

Locals now get arrays for their nested array fields, except trailing arrays of length 0 or 1,
which may be flexible. Array fields decay to their arrays in calls and models. String literals
and struct copies are copied into the destination's arrays instead of replacing them, which
removes false positives on initializers such as struct S s = {{0}, "abc"}; or a C++
char name[16] = "";. Part of #1444, with #2192. #2208's eval_array replaces eval_arg only
in the StdArray models.

Test plan

New tests in c/bufferoverrun and cpp/bufferoverrun; FN_call_access_index_4_on_S2_Bad is
now reported and renamed. The codetoanalyze tests pass. With --bufferoverrun-only: lua
(without lgc.c) -2 INTEGER_OVERFLOW_L2, civetweb -1 BUFFER_OVERRUN_L3, libuv +1 runtime-safe
BUFFER_OVERRUN_L2 (as for local arrays); zlib, cJSON, libyaml and hiredis unchanged.

@meta-cla meta-cla Bot added the CLA Signed label Oct 2, 2026
VladimirMakaev added a commit to VladimirMakaev/infer that referenced this pull request Oct 3, 2026
Inferbo knew a global array's size only from its initializer, so it missed overruns of
uninitialized global arrays (facebook#949), of static local arrays and of array fields of global structs.
A store `g[i] = v` also overwrote the whole array value of `g`.

```c
int arr[50];

void write_all() {
  for (int i = 0; i <= 50; i++) {
    arr[i] = 1; // Infer missed: buffer overrun
  }
}
```

The clang frontend now records the declared types of the global arrays and structs each procedure
references. Inferbo gives these arrays symbolic contents of that size, stores update their
elements, and only `const` arrays take their contents from their initializer. Symbols reached
through globals are traced as `Global`, not `Parameter`.

Limitations:
- array fields of global structs passed to calls or `strcpy` need facebook#2185 too (together: facebook#1444);
- element stores are weak: after `g[1] = 3`, `g[1]` is a range;
- Inferbo's usual imprecision reaches these arrays too (a few new reports on lua and zlib).

## Test plan

New tests in `c/bufferoverrun/global.c`, `cpp/bufferoverrun/global.cpp`,
`cpp/bufferoverrun/std_array.cpp` and `c/performance/loops.c`; `issue949_bad_FN` becomes
`issue949_bad`. The addresses of two mutable global arrays are no longer known to differ, which
adds 1 to the cost of `loop_use_global_vars` (C and ObjC). The C/C++ codetoanalyze tests pass, as
do the ObjC tests on global arrays.
@VladimirMakaev
VladimirMakaev force-pushed the inferbo-struct-array-fields branch from 350060b to b77d21d Compare October 3, 2026 21:52
VladimirMakaev added a commit to VladimirMakaev/infer that referenced this pull request Oct 5, 2026
Inferbo knew a global array's size only from its initializer, so it missed overruns of
uninitialized global arrays (facebook#949), of static local arrays and of array fields of global structs.
A store `g[i] = v` also overwrote the whole array value of `g`.

```c
int arr[50];

void write_all() {
  for (int i = 0; i <= 50; i++) {
    arr[i] = 1; // Infer missed: buffer overrun
  }
}
```

The clang frontend records the declared types of the globals each procedure references.
Inferbo gives these arrays symbolic contents of that size, stores update their elements, a row
`g[i]` used as `int*` points to its first element, and only `const` arrays take their contents
from their initializer.

Limitations:
- array fields of global structs passed to calls or `strcpy` need facebook#2185 too (together: facebook#1444);
- elements are weak (`if (g[1] > 3)` bounds no later read) and conditions on them are reported
  in each caller, as for other globals;
- pointers to rows (`int (*q)[4] = &g[1]; (*q)[3]`) keep Inferbo's imprecision for local arrays.

## Test plan

New tests in `c/bufferoverrun/global.c`, `cpp/bufferoverrun/global.cpp`,
`cpp/bufferoverrun/std_array.cpp` and `c/performance/loops.c`; `issue949_bad_FN` becomes
`issue949_bad`. The addresses of two mutable global arrays are no longer known to differ, which
adds 1 to the cost of `loop_use_global_vars` (C and ObjC). The C/C++ codetoanalyze tests pass.
Inferbo declared no arrays for the array fields of local structs and C++ objects, so their
accesses went unchecked. Array fields passed to functions or models, as in `g(s.arr)` or
`strcpy(p->name, src)`, evaluated to the field's cell instead of its array, also for heap and
parameter structs.

```c
#include <string.h>

struct S {
  int arr[4];
  char name[8];
};

void f(void) {
  struct S s;
  s.arr[4] = 0; // Infer missed: buffer overrun
  strcpy(s.name, "12345678"); // Infer missed: buffer overrun
}
```

Locals now get arrays for their nested array fields, except trailing arrays of length 0 or 1,
which may be flexible. Array fields decay to their arrays in calls and models. String literals
and struct copies are copied into the destination's arrays instead of replacing them, which
removes false positives on initializers such as `struct S s = {{0}, "abc"};` or a C++
`char name[16] = "";`. Part of facebook#1444, with facebook#2192. facebook#2208's `eval_array` replaces `eval_arg` only
in the `StdArray` models.

## Test plan

New tests in `c/bufferoverrun` and `cpp/bufferoverrun`; `FN_call_access_index_4_on_S2_Bad` is
now reported and renamed. The codetoanalyze tests pass. With `--bufferoverrun-only`: lua
(without `lgc.c`) -2 INTEGER_OVERFLOW_L2, civetweb -1 BUFFER_OVERRUN_L3, libuv +1 runtime-safe
BUFFER_OVERRUN_L2 (as for local arrays); zlib, cJSON, libyaml and hiredis unchanged.
@VladimirMakaev
VladimirMakaev force-pushed the inferbo-struct-array-fields branch from b77d21d to f62780b Compare October 5, 2026 06:53
VladimirMakaev added a commit to VladimirMakaev/infer that referenced this pull request Oct 5, 2026
Inferbo knew a global array's size only from its initializer, so it missed overruns of
uninitialized global arrays (facebook#949), of static local arrays and of array fields of global structs.
A store `g[i] = v` also overwrote the whole array value of `g`.

```c
int arr[50];

void write_all() {
  for (int i = 0; i <= 50; i++) {
    arr[i] = 1; // Infer missed: buffer overrun
  }
}
```

The clang frontend records the declared types of the globals each procedure references.
Inferbo gives these arrays symbolic contents of that size, stores update their elements, a row
`g[i]` used as `int*` points to its first element, and only `const` arrays take their contents
from their initializer.

Limitations:
- array fields of global structs passed to calls or `strcpy` need facebook#2185 too (together: facebook#1444);
- elements are weak (`if (g[1] > 3)` bounds no later read) and conditions on them are reported
  in each caller, as for other globals;
- pointers to rows (`int (*q)[4] = &g[1]; (*q)[3]`) keep Inferbo's imprecision for local arrays.

## Test plan

New tests in `c/bufferoverrun/global.c`, `cpp/bufferoverrun/global.cpp`,
`cpp/bufferoverrun/std_array.cpp` and `c/performance/loops.c`; `issue949_bad_FN` becomes
`issue949_bad`. The addresses of two mutable global arrays are no longer known to differ, which
adds 1 to the cost of `loop_use_global_vars` (C and ObjC). The C/C++ codetoanalyze tests pass.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant