In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix mc_data out-of-bounds read warning
Clear warning that read mc_data[i-1] may out-of-bounds.
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix ucode out-of-bounds read warning
Clear warning that read ucode[] may out-of-bounds.
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_number
Check the fb_channel_number range to avoid the array out-of-bounds
read error
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix out-of-bounds write warning
Check the ring type value to fix the out-of-bounds
write warning
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Ensure index calculation will not overflow
[WHY & HOW]
Make sure vmid0p72_idx, vnom0p8_idx and vmax0p9_idx calculation will
never overflow and exceess array size.
This fixes 3 OVERRUN and 1 INTEGER_OVERFLOW issues reported by Coverity.
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add otg_master NULL check within resource_log_pipe_topology_update
[Why]
Coverity reports NULL_RETURN warning.
[How]
Add otg_master NULL check.
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check index for aux_rd_interval before using
aux_rd_interval has size of 7 and should be checked.
This fixes 3 OVERRUN and 1 INTEGER_OVERFLOW issues reported by Coverity.
In the Linux kernel, the following vulnerability has been resolved:
thunderbolt: Mark XDomain as unplugged when router is removed
I noticed that when we do discrete host router NVM upgrade and it gets
hot-removed from the PCIe side as a result of NVM firmware authentication,
if there is another host connected with enabled paths we hang in tearing
them down. This is due to fact that the Thunderbolt networking driver
also tries to cleanup the paths and ends up blocking in
tb_disconnect_xdomain_paths() waiting for the domain lock.
However, at this point we already cleaned the paths in tb_stop() so
there is really no need for tb_disconnect_xdomain_paths() to do that
anymore. Furthermore it already checks if the XDomain is unplugged and
bails out early so take advantage of that and mark the XDomain as
unplugged when we remove the parent router.
In the Linux kernel, the following vulnerability has been resolved:
drm/xe: reset mmio mappings with devm
Set our various mmio mappings to NULL. This should make it easier to
catch something rogue trying to mess with mmio after device removal. For
example, we might unmap everything and then start hitting some mmio
address which has already been unmamped by us and then remapped by
something else, causing all kinds of carnage.
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3
On a system with a GICv3, if a guest hasn't been configured with
GICv3 and that the host is not capable of GICv2 emulation,
a write to any of the ICC_*SGI*_EL1 registers is trapped to EL2.
We therefore try to emulate the SGI access, only to hit a NULL
pointer as no private interrupt is allocated (no GIC, remember?).
The obvious fix is to give the guest what it deserves, in the
shape of a UNDEF exception.