CWE-119

Nanopb is a small code-size Protocol Buffers implementation. In Nanopb before versions 0.4.4 and 0.3.9.7, decoding specifically formed message can leak memory if dynamic allocation is enabled and an oneof field contains a static submessage that contains a dynamic field, and the message being decoded contains the submessage multiple times. This is rare in normal messages, but it is a concern when untrusted data is parsed. This is fixed in versions 0.3.9.7 and 0.4.4. The following workarounds are available: 1) Set the option `no_unions` for the oneof field. This will generate fields as separate instead of C union, and avoids triggering the problematic code. 2) Set the type of the submessage field inside oneof to `FT_POINTER`. This way the whole submessage will be dynamically allocated and the problematic code is not executed. 3) Use an arena allocator for nanopb, to make sure all memory can be released afterwards.

An out-of-bounds write flaw was found in FontForge in versions before 20200314 while parsing SFD files containing certain LayerCount tokens. This flaw allows an attacker to manipulate the memory allocated on the heap, causing the application to crash or execute arbitrary code. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability.

An issue was discovered in Xen through 4.14.x. There are evtchn_reset() race conditions. Uses of EVTCHNOP_reset (potentially by a guest on itself) or XEN_DOMCTL_soft_reset (by itself covered by XSA-77) can lead to the violation of various internal assumptions. This may lead to out of bounds memory accesses or triggering of bug checks. In particular, x86 PV guests may be able to elevate their privilege to that of the host. Host and guest crashes are also possible, leading to a Denial of Service (DoS). Information leaks cannot be ruled out. All Xen versions from 4.5 onwards are vulnerable. Xen versions 4.4 and earlier are not vulnerable.

xmlquery before 1.3.1 lacks a check for whether a LoadURL response is in the XML format, which allows attackers to cause a denial of service (SIGSEGV) at xmlquery.(*Node).InnerText or possibly have unspecified other impact.

A safety violation was discovered in the rgb crate before 0.8.20 for Rust, leading to (for example) dereferencing of arbitrary pointers or disclosure of uninitialized memory. This occurs because structs can be treated as bytes for read and write operations.