CWE-754

A vulnerability exists in the Palo Alto Network PAN-OS signature-based threat detection engine that allows an attacker to communicate with devices in the network in a way that is not analyzed for threats by sending data through specifically crafted TCP packets. This technique evades signature-based threat detection. This issue impacts: PAN-OS 8.1 versions earlier than 8.1.17; PAN-OS 9.0 versions earlier than 9.0.11; PAN-OS 9.1 versions earlier than 9.1.5; All versions of PAN-OS 7.1 and PAN-OS 8.0.

The time check operation of PepeAuctionSale 1.0 can be rendered ineffective by assigning a large number to the _duration variable, compromising access control to the application.

gdm3 versions before 3.36.2 or 3.38.2 would start gnome-initial-setup if gdm3 can’t contact the accountservice service via dbus in a timely manner; on Ubuntu (and potentially derivatives) this could be be chained with an additional issue that could allow a local user to create a new privileged account.

An issue was discovered in Xen through 4.13.x, allowing guest OS users to cause a host OS crash because of incorrect error handling in event-channel port allocation. The allocation of an event-channel port may fail for multiple reasons: (1) port is already in use, (2) the memory allocation failed, or (3) the port we try to allocate is higher than what is supported by the ABI (e.g., 2L or FIFO) used by the guest or the limit set by an administrator (max_event_channels in xl cfg). Due to the missing error checks, only (1) will be considered an error. All the other cases will provide a valid port and will result in a crash when trying to access the event channel. When the administrator configured a guest to allow more than 1023 event channels, that guest may be able to crash the host. When Xen is out-of-memory, allocation of new event channels will result in crashing the host rather than reporting an error. Xen versions 4.10 and later are affected. All architectures are affected. The default configuration, when guests are created with xl/libxl, is not vulnerable, because of the default event-channel limit.

In ORY Fosite (the security first OAuth2 & OpenID Connect framework for Go) before version 0.34.0, the `TokenRevocationHandler` ignores errors coming from the storage. This can lead to unexpected 200 status codes indicating successful revocation while the token is still valid. Whether an attacker can use this for her advantage depends on the ability to trigger errors in the store. This is fixed in version 0.34.0