• The heap initialization methods were missing a minimum size check for the given heap size argument. This could lead to out-of-bound writes when a heap was initialized with a size smaller than 3 * size_of::<usize> because of metadata write operations.
• When calling Heap::extend with a size smaller than two usizes (e.g., 16 on x86_64), the size was erroneously rounded up to the minimum size, which could result in an out-of-bounds write.
• Calling Heap::extend on an empty heap tried to construct a heap starting at address 0, which is also an out-of-bounds write.
  • One specific way to trigger this accidentally is to call Heap::new (or a similar constructor) with a heap size that is smaller than two usizes. This was treated as an empty heap as well.
• Calling Heap::extend on a heap whose size is not a multiple of the size of two usizes resulted in unaligned writes. It also left the heap in an unexpected state, which might lead to subsequent issues. We did not find a way to exploit this undefined behavior yet (apart from DoS on platforms that fault on unaligned writes).

On Windows, configuring a named pipe server with pipe_mode will force ServerOptions::reject_remote_clients as false.

This drops any intended explicit configuration for the reject_remote_clients that may have been set as true previously.

The default setting of reject_remote_clients is normally true meaning the default is also overridden as false.

Workarounds

Ensure that pipe_mode is set first after initializing a ServerOptions. For example:

let mut opts = ServerOptions::new();
opts.pipe_mode(PipeMode::Message);
opts.reject_remote_clients(true);