Insufficient compartmentalization in HECI subsystem for the Intel(R) SPS before versions SPS_E5_04.01.04.516.0, SPS_E5_04.04.04.033.0, SPS_E5_04.04.03.281.0, SPS_E5_03.01.03.116.0, SPS_E3_05.01.04.309.0, SPS_02.04.00.101.0, SPS_SoC-A_05.00.03.114.0, SPS_SoC-X_04.00.04.326.0, SPS_SoC-X_03.00.03.117.0, IGN_E5_91.00.00.167.0, SPS_PHI_03.01.03.078.0 may allow an authenticated user to potentially enable escalation of privilege via physical access.

Improper input validation in the firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access.

Race condition in the firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access.

Observable timing discrepancy in some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.

Improper isolation of shared resources in some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.

Improper input validation in the firmware for some Intel(R) Processors may allow an authenticated user to potentially enable denial of service via local access.

Out of bounds read in the firmware for some Intel(R) Processors may allow an authenticated user to potentially enable escalation of privilege via local access.

Insufficient control flow management in the firmware for some Intel(R) Processors may allow an unauthenticated user to potentially enable escalation of privilege via physical access.

Out of bounds write in the firmware for some Intel(R) Processors may allow a privileged user to potentially enable denial of service via local access.

Improper initialization in the firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access.

An issue was discovered in the Linux kernel through 5.10.1, as used with Xen through 4.14.x. The Linux kernel PV block backend expects the kernel thread handler to reset ring->xenblkd to NULL when stopped. However, the handler may not have time to run if the frontend quickly toggles between the states connect and disconnect. As a consequence, the block backend may re-use a pointer after it was freed. A misbehaving guest can trigger a dom0 crash by continuously connecting / disconnecting a block frontend. Privilege escalation and information leaks cannot be ruled out. This only affects systems with a Linux blkback.

An issue was discovered in the Linux kernel before 5.7.3, related to mm/gup.c and mm/huge_memory.c. The get_user_pages (aka gup) implementation, when used for a copy-on-write page, does not properly consider the semantics of read operations and therefore can grant unintended write access, aka CID-17839856fd58.

Improper access control in BIOS firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access.

Out of bounds write in Intel BIOS platform sample code for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access.

Use of potentially dangerous function in Intel BIOS platform sample code for some Intel(R) Processors may allow an authenticated user to potentially enable escalation of privilege via local access.

Improper conditions check in Intel BIOS platform sample code for some Intel(R) Processors before may allow a privileged user to potentially enable escalation of privilege via local access.

Improper isolation of shared resources in some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.

A flaw was found in the Linux kernel in versions before 5.9-rc7. Traffic between two Geneve endpoints may be unencrypted when IPsec is configured to encrypt traffic for the specific UDP port used by the GENEVE tunnel allowing anyone between the two endpoints to read the traffic unencrypted. The main threat from this vulnerability is to data confidentiality.