Hello there. I've read comments in PoolingAllocatorConfig / PoolingInstanceAllocator and my understanding is that regardless of the settings the pooling allocator could not leak data neither to subsequent guest module instances when memory is reused nor to other OS processes when the memory is returned to the system. The reason I am uncertain is the fact that some things as marked on Linux only, and also there are two strategy involved (memset vs madvice), which makes it harder for me to understand as I am not that familiar with these lower level details.
Could you please confirm that even if pooling allocator is used, data from memory could not leak to other module instances or OS processes, or - in other words - that pooling allocator is NOT a trade-off between safety and performance?
Your understanding of this is correct, yes. Any ability of guest code to access memory outside of its instance sandbox as initialized for that particular instance would be treated as a critical CVE.
The different strategies make use of different sets of functionality provided by the OS to optimize for different performance/resource consumption goals as enabled by the underlying OS (and CPU, where applicable.) All of this is purely in the realm of transparent optimizations, without any tradeoffs to security. To the degree possible these different strategies are also all covered by fuzzing. (The key limit is that OSS-Fuzz, where our CI fuzzing runs, only supports Linux, so that's the platform with the best assurances for operational reasons.)
And to add on to what Till says here
Till Schneidereit said:
Any ability of guest code to access memory outside of its instance sandbox as initialized for that particular instance would be treated as a critical CVE.
this sandboxing is also temporal, not just spatial. That is, new instances cannot observe any data from past instances that happened to use the same pooling slot (and any bug that somehow enabled this would be considered a critical CVE).
Last updated: Dec 06 2025 at 06:05 UTC