Comments (6)
nacho
commented on June 26, 2024
Hey, can you start providing a patch with the first option so it can be discussed with a MR in place? Thanks
from protobuf-c.
edmonds
commented on June 26, 2024
Hi, @smuellerDD, thanks for the report and the patch.
I don't doubt that you ran into a memory corruption issue but I'm curious if you can provide more details about the exact circumstances that were required in order to get protobuf_c_message_unpack() to return a ProtobufCMessage * with an uninitialized unknown_fields? If protobuf-c were always returning uninitialized memory there I'd expect a lot more crashes and bug reports since that kind of bug would tend to light up Valgrind and the various sanitizers.
After the initial do_alloc() here:
protobuf-c/protobuf-c/protobuf-c.c
Line 3063 in 67b1c35
We perform initialization here:
protobuf-c/protobuf-c/protobuf-c.c
Lines 3085 to 3088 in 67b1c35
In the first branch, if the message descriptor was generated by the protobuf-c compiler we should eventually end up calling PROTOBUF_C_MESSAGE_INIT which will zero all three fields of the ProtobufCMessage:
protobuf-c/protobuf-c/protobuf-c.h
Line 999 in 67b1c35
In the second branch, we should be calling memset() to zero the whole thing:
protobuf-c/protobuf-c/protobuf-c.c
Line 2950 in 67b1c35
Are you by chance using your own ProtobufCMessageDescriptor rather than one generated by the protobuf-c compiler?
from protobuf-c.
edmonds
commented on June 26, 2024
Also, my preference for fixing this would be to immediately do a *rv = {0}; right after the allocation succeeds, it's a little bit weird that the protobuf-c code base doesn't do this everywhere memory is allocated. Perhaps we should make do_alloc() always do a memset and take the probably negligible performance hit in exchange for more assurance that we're not using uninitialized memory somewhere.
from protobuf-c.
smuellerDD
commented on June 26, 2024
Am Sonntag, 21. Januar 2024, 16:39:46 CET schrieb Robert Edmonds:
Hi Robert,
Also, my preference for fixing this would be to immediately do a `*rv =
{0};` right after the allocation succeeds, it's a little bit weird that the
protobuf-c code base doesn't do this everywhere memory is allocated.
Perhaps we should make `do_alloc()` always do a `memset` and take the
probably negligible performance hit in exchange for more assurance that
we're not using uninitialized memory somewhere.
The easiest would be a calloc instead of a malloc.
Ciao
Stephan
from protobuf-c.
edmonds
commented on June 26, 2024
The easiest would be a calloc instead of a malloc. Ciao Stephan
Right, but we can't directly call calloc() since protobuf-c wraps memory allocations using ProtobufCAllocator so that the library user can provide their own allocation functions. So we could either introduce a do_calloc() that calls the alloc function in the allocator and does a memset() or we could make do_alloc() always zero out all memory allocations.
from protobuf-c.
smuellerDD
commented on June 26, 2024
Am Sonntag, 21. Januar 2024, 16:31:56 CET schrieb Robert Edmonds:
Hi Robert,
Are you by chance using your own `ProtobufCMessageDescriptor` rather than
one generated by the protobuf-c compiler?
I am using a pretty standard code I would assume where seemingly I do not
replace any data structure. However, I implement an RPC mechanism (one example
of the implementation is in [1]). Yet, in addition, I wrap one protobuf
definition into another to implement a cryptographic protocol around a regular
RPC interface.
I.e. I have an outer protobuf call for the secure connection described in [3]
followed by an internal protobuf definition with the various RPC calls I want
to have.
The outer calls the inner with the ->invoke operation after the outer layer
decrypted the data. In addition, when the inner layer completes, it writes the
data into a buffer when calling protobuf_c_message_pack_to_buffer by providing
my own base.append implementation.
In addition, for performance reason I have my own allocator which uses stack
memory shown in [2].
Note, the funny thing is that I never experienced a crash, but valgrind showed
me invalid memory accesses which I traced down to this location. Note, the
invalid memory accesses were only off by up to 8 bytes. On Linux this usually
does not cause a crash as this is somehow within the bounds of guard pages or
similar mechanism that would prevent such crash.
[1] https://github.com/smuellerDD/esdm/blob/master/service-rpc/client/
esdm_rpc_client.c and https://github.com/smuellerDD/esdm/blob/master/service-rpc/server/esdm_rpc_server.c
[2] https://github.com/smuellerDD/esdm/blob/master/service-rpc/service/
esdm_rpc_protocol.c#L28
[3] http://www.chronox.de/papers/KyberKEX_2way_handshake_specification.pdf
Ciao
Stephan
from protobuf-c.
Related Issues (20)
- uninitialized variable compile error with GCC 10.3 HOT 1
- import in protobuf-c.proto causes 'file not found' error with Visual Studio 2019 HOT 3
- unsigned integer overflow HOT 5
- UndefinedBehaviorSanitizer: invalid left shift in protobuf-c.c:2086 HOT 1
- 1.4.0: build faiuls with latest gcc HOT 3
- error: ‘const class google::protobuf::OneofDescriptor’ has no member named ‘file’ HOT 4
- Fix a clang analyzer 14 warning about a possible NULL deref.
- support proto3 optional HOT 1
- cppcheck 2.8 lints HOT 2
- protobuf-c 1.4.x cygwin (win10pro) build fails HOT 4
- Does not compile under Debian 11.5 HOT 7
- Undefined reference when linking protobuf-c statically HOT 1
- protobuf-c 1.4.1 won't build against protobuf 22.1 HOT 18
- The libprotobuf-c.so.1.0.0 gets generated instead of a libprotobuf-c.so.1.4.0, why is that? HOT 2
- Integrate with schema registry
- Missing Config.cmake.in in 1.5.0 protobuf-c-1.5.0.tar.gz archive
- cannot compile in V1.5.0 HOT 1
- build fiailed，error: cmake -E env: unknown option '--'
- Cannot compile protobuf-c HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from protobuf-c.