Access of Resource Using Incompatible Type ('Type Confusion')

In venc, there is a possible out of bounds write due to type confusion. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS08737250; Issue ID: MSV-1452.Show less

In gpu_pm_power_on_top_nolock of pixel_gpu_power.c, there is a possible compromise of protected memory due to a logic error in the code. This could lead to local escalation of privilege to TEE with no additional execution privileges needed. User interaction is not needed for exploitation.Show less

In lwis_add_completion_fence of lwis_fence.c, there is a possible escalation of privilege due to type confusion. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Show less

In handle_init of goodix/main/main.c, there is a possible memory corruption due to type confusion. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Show less

Unlike 32-bit PV guests, HVM guests may switch freely between 64-bit and other modes. This in particular means that they may set registers used to pass 32-bit-mode hypercall arguments to values outside of the range 32-bit code would be able to set them to. When processing of hypercalls takes a considerable amount of time, the hypervisor may choose to invoke a hypercall continuation. Doing so involves putting (perhaps updated) hypercall arguments in respective registers. For guests not running in 64-bit mode this further involves a certain amount of translation of the values. Unfortunately internal sanity checking of these translated values assumes high halves of registers to always be clear when invoking a hypercall. When this is found not to be the case, it triggers a consistency check in the hypervisor and causes a crash. Show less