Update security model with regards to pointer fields

docs/security.rst

@@ -26,9 +26,9 @@ The following data is regarded as **trusted**. It must be under the control of
 the application writer. Malicious data in these structures could cause
 security issues, such as execution of arbitrary code:
 
-1. Callback and extension fields in message structures given to pb_encode()
-   and pb_decode(). These fields are memory pointers, and are generated
-   depending on the .proto file.
+1. Callback, pointer and extension fields in message structures given to
+   pb_encode() and pb_decode(). These fields are memory pointers, and are
+   generated depending on the message definition in the .proto file.
 2. The automatically generated field definitions, i.e. *pb_field_t* lists.
 3. Contents of the *pb_istream_t* and *pb_ostream_t* structures (this does not
    mean the contents of the stream itself, just the stream definition).
@@ -38,7 +38,7 @@ these will cause "garbage in, garbage out" behaviour. It will not cause
 buffer overflows, information disclosure or other security problems:
 
 1. All data read from *pb_istream_t*.
-2. All fields in message structures, except callbacks and extensions.
+2. All fields in message structures, except callbacks, pointers and extensions.
    (Beginning with nanopb-0.2.4, in earlier versions the field sizes are partially unchecked.)
 
 Invariants
@@ -76,4 +76,6 @@ The following list is not comprehensive:
    stop a denial of service attack from using an infinite message.
 4. If using network sockets as streams, a timeout should be set to stop
    denial of service attacks.
-
+5. If using *malloc()* support, some method of limiting memory use should be
+   employed. This can be done by defining custom *pb_realloc()* function.
+   Nanopb will properly detect and handle failed memory allocations.