In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Use kvfree instead of kfree in amdgpugmcgetnpsmemranges()
amdgpudiscoverygetnpsinfo() internally allocates memory for ranges using kvcalloc(), which may use vmalloc() for large allocation. Using kfree() to release vmalloc memory will lead to a memory corruption.
Use kvfree() to safely handle both kmalloc and vmalloc allocations.
Compile tested only. Issue found using a prototype static analysis tool and code review.
drm/amdgpu: add upper bound check on user inputs in wait ioctl
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/userq: Fix reference leak in amdgpuuserqwaitioctl
Drop reference to syncobj and timeline fence when aborting the ioctl due output array being too small.
(cherry picked from commit 68951e9c3e6bb22396bc42ef2359751c8315dd27)
drm/amdgpu: add upper bound check on user inputs in signal ioctl
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix sync handling in amdgpudmabufmovenotify
Invalidating a dmabuf will impact other users of the shared BO. In the scenario where process A moves the BO, it needs to inform process B about the move and process B will need to update its page table.
The commit fixes a synchronisation bug caused by the use of the ticket: it made amdgpuvmhandlemoved behave as if updating the page table immediately was correct but in this case it's not.
An example is the following scenario, with 2 GPUs and glxgears running on GPU0 and Xorg running on GPU1, on a system where P2P PCI isn't supported:
glxgears: export linear buffer from GPU0 and import using GPU1 submit frame rendering to GPU0 submit tiled->linear blit Xorg: copy of linear buffer
The sequence of jobs would be: drmschedjobrun # GPU0, frame rendering drmschedjobqueue # GPU0, blit drmschedjobdone # GPU0, frame rendering drmschedjobrun # GPU0, blit move linear buffer for GPU1 access # amdgpudmabufmovenotify -> update pt # GPU0
It this point the blit job on GPU0 is still running and would likely produce a page fault.
drm/amdgpu/ras: Move ras data alloc before bad page check
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: disable sdma ecc irq only when sdma RAS is enabled in suspend
sdmav40ip is shared on a few asics, but in sdmav40hwfini, driver unconditionally disables eccirq which is only enabled on those asics enabling sdma ecc. This will introduce a warning in suspend cycle on those chips with sdma ip v4.0, while without sdma ecc. So this patch correct this.
[ 7283.166354] RIP: 0010:amdgpuirqput+0x45/0x70 [amdgpu] [ 7283.167001] RSP: 0018:ffff9a5fc3967d08 EFLAGS: 00010246 [ 7283.167019] RAX: ffff98d88afd3770 RBX: 0000000000000001 RCX: 0000000000000000 [ 7283.167023] RDX: 0000000000000000 RSI: ffff98d89da30390 RDI: ffff98d89da20000 [ 7283.167025] RBP: ffff98d89da20000 R08: 0000000000036838 R09: 0000000000000006 [ 7283.167028] R10: ffffd5764243c008 R11: 0000000000000000 R12: ffff98d89da30390 [ 7283.167030] R13: ffff98d89da38978 R14: ffffffff999ae15a R15: ffff98d880130105 [ 7283.167032] FS: 0000000000000000(0000) GS:ffff98d996f00000(0000) knlGS:0000000000000000 [ 7283.167036] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 7283.167039] CR2: 00000000f7a9d178 CR3: 00000001c42ea000 CR4: 00000000003506e0 [ 7283.167041] Call Trace: [ 7283.167046] <TASK> [ 7283.167048] sdmav40hwfini+0x38/0xa0 [amdgpu] [ 7283.167704] amdgpudeviceipsuspendphase2+0x101/0x1a0 [amdgpu] [ 7283.168296] amdgpudevicesuspend+0x103/0x180 [amdgpu] [ 7283.168875] amdgpupmopsfreeze+0x21/0x60 [amdgpu] [ 7283.169464] pcipmfreeze+0x54/0xc0