CVE-2026-68436: drm/amd/display: use kvzalloc to allocate struct dc

In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: use kvzalloc to allocate struct dc

struct dc has grown large over time (most of it the two inlined dcscratchspace copies) and now sits close to the page allocator's 4 MiB contiguous allocation limit. Its actual size is not fixed by the source alone, it also depends on the compiler and the .config, so it can easily cross 4 MiB, e.g. with a newer GCC or a config change.

dccreate() allocates it with kzalloc(). Once struct dc exceeds 4 MiB the request is rounded up to order 11 (8 MiB), which is above MAXPAGEORDER, so the page allocator warns and returns NULL. dccreate() then fails, DM init fails and amdgpu probe aborts with -EINVAL:

WARNING: mm/pagealloc.c:5197 at allocfrozenpagesnoprof+0x2f9/0x380 dccreate+0x38/0x660 [amdgpu] amdgpudminit+0x2d9/0x510 [amdgpu] dmhwinit+0x1b/0x90 [amdgpu] amdgpudeviceinit.cold+0x150d/0x1e13 [amdgpu] amdgpudriverloadkms+0x19/0x80 [amdgpu] amdgpupciprobe+0x1e2/0x4c0 [amdgpu]

dccreate() then returns NULL and DM init fails, which aborts the whole GPU init and makes amdgpu probe fail with -EINVAL ("hwinit of IP block <dm> failed -22"), leaving the display unusable. The subsequent amdgpuirqput() warnings during teardown are just fallout of unwinding a half-initialized device.

struct dc is a software-only bookkeeping structure that is never handed to hardware DMA and is only ever kept as an opaque pointer, so it does not require physically contiguous memory. Allocate it with kvzalloc() (and free it with kvfree()) so that the allocator can fall back to vmalloc() when a contiguous allocation of that size is not available, which also avoids the MAXPAGEORDER warning entirely.

v2: - Rebase to amd-staging-drm-next.

(cherry picked from commit 991e0516a8072f2292681c6ae98a924ab0e32575)