diff options
| author | Petteri Aimonen <jpa@git.mail.kapsi.fi> | 2019-10-02 10:56:49 +0300 |
|---|---|---|
| committer | Petteri Aimonen <jpa@git.mail.kapsi.fi> | 2019-10-02 11:16:51 +0300 |
| commit | eab98ebbd68489987b8399d37cf5517792353fc7 (patch) | |
| tree | 57c2d8f7d9749de5ea8031ad1872953daba4957e /docs | |
| parent | 186ee03dd3d2e66204646863eee61d7e5d01c272 (diff) | |
Fix undefined behavior with bool fields (#434)
Previously nanopb didn't enforce that decoded bool fields
had valid true/false values. This could lead to undefined
behavior in user code.
This has potential security implications when
1) message contains bool field (has_ fields are safe)
and
2) user code uses ternary operator dependent on the field value,
such as: int value = msg.my_bool ? 1234 : 0
and
3) the value returned from ternary operator affects a memory access,
such as: data_array[value] = 9999
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/migration.rst | 16 | ||||
| -rw-r--r-- | docs/security.rst | 1 |
2 files changed, 17 insertions, 0 deletions
diff --git a/docs/migration.rst b/docs/migration.rst index f553d4a..4aceb95 100644 --- a/docs/migration.rst +++ b/docs/migration.rst @@ -154,6 +154,22 @@ define always has the largest value. are not defined in ascending order, user code behaviour may change. Check that user code doesn't expect the old, incorrect first/last behaviour. +Fix undefined behavior related to bool fields +--------------------------------------------- + +**Rationale:** In C99, `bool` variables are not allowed to have other values +than `true` and `false`. Compilers use this fact in optimization, and constructs +like `int foo = msg.has_field ? 100 : 0` will give unexpected results otherwise. +Previously nanopb didn't enforce that decoded bool fields had valid values. + +**Changes:** Bool fields are now handled separately as `PB_LTYPE_BOOL`. The +`LTYPE` descriptor numbers for other field types were renumbered. + +**Required actions:** Source code files must be recompiled, but regenerating +`.pb.h`/`.pb.c` files from `.proto` is not required. If user code directly uses +the nanopb internal field representation (search for `PB_LTYPE_VARINT` in source), +it may need updating. + Nanopb-0.3.9.1, 0.4.0 (2018-04-14) ================================== diff --git a/docs/security.rst b/docs/security.rst index d854612..6f7152e 100644 --- a/docs/security.rst +++ b/docs/security.rst @@ -58,6 +58,7 @@ untrusted data has been maliciously crafted: - The *count* fields of arrays will not exceed the array size. - The *size* field of bytes will not exceed the allocated size. - All string fields will have null terminator. + - bool fields will have valid true/false values (since nanopb-0.3.9.4) 5. After pb_encode() returns successfully, the resulting message is a valid protocol buffers message. (Except if user-defined callbacks write incorrect |