An issue was discovered in adns before 1.5.2. adnshost mishandles a missing final newline on a stdin read. It is wrong to increment used as well as setting r, since used is incremented according to r, later. Rather one should be doing what read() would have done. Without this fix, adnshost may read and process one byte beyond the buffer, perhaps crashing or perhaps somehow leaking the value of that byte.
An issue was discovered in adns before 1.5.2. It fails to ignore apparent answers before the first RR that was found the first time. when this is fixed, the second answer scan finds the same RRs at the first. Otherwise, adns can be confused by interleaving answers for the CNAME target, with the CNAME itself. In that case the answer data structure (on the heap) can be overrun. With this fixed, it prefers to look only at the answer RRs which come after the CNAME, which is at least arguably correct.
In the Linux kernel before 5.4.16, a race condition in tty->disc_data handling in the slip and slcan line discipline could lead to a use-after-free, aka CID-0ace17d56824. This affects drivers/net/slip/slip.c and drivers/net/can/slcan.c.
In ISC BIND9 versions BIND 9.11.14 -> 9.11.19, BIND 9.14.9 -> 9.14.12, BIND 9.16.0 -> 9.16.3, BIND Supported Preview Edition 9.11.14-S1 -> 9.11.19-S1: Unless a nameserver is providing authoritative service for one or more zones and at least one zone contains an empty non-terminal entry containing an asterisk ("*") character, this defect cannot be encountered. A would-be attacker who is allowed to change zone content could theoretically introduce such a record in order to exploit this condition to cause denial of service, though we consider the use of this vector unlikely because any such attack would require a significant privilege level and be easily traceable.
An attacker who is permitted to send zone data to a server via zone transfer can exploit this to intentionally trigger the assertion failure with a specially constructed zone, denying service to clients.
An issue was discovered in LibVNCServer before 0.9.13. Byte-aligned data is accessed through uint32_t pointers in libvncclient/rfbproto.c. NOTE: there is reportedly "no trust boundary crossed.
An issue was discovered in LibVNCServer before 0.9.13. Byte-aligned data is accessed through uint16_t pointers in libvncserver/translate.c. NOTE: Third parties do not consider this to be a vulnerability as there is no known path of exploitation or cross of a trust boundary
Incomplete cleanup from specific special register read operations in some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.