CVE-2026-52951

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/dma-buf: handle empty bo and UAF races<br /> <br /> There look to be some nasty races here when triggering the<br /> invalidate_mappings hook:<br /> <br /> 1) We do xe_bo_alloc() followed by the attach, before the actual full bo<br /> init step in xe_dma_buf_init_obj(). However the bo is visible on the<br /> attachments list after the attach. This is bad since exporter driver,<br /> say amdgpu, can at any time call back into our invalidate_mappings hook,<br /> with an empty/bogus bo, leading to potential bugs/crashes.<br /> <br /> 2) Similar to 1) but here we get a UAF, when the invalidate_mappings<br /> hook is triggered. For example, we get as far as xe_bo_init_locked()<br /> but this fails in some way. But here the bo will be freed on error, but<br /> we still have it attached from dma-buf pov, so if the<br /> invalidate_mappings is now triggered then the bo we access is gone and<br /> we trigger UAF and more bugs/crashes.<br /> <br /> To fix this, move the attach step until after we actually have a fully<br /> set up buffer object. Note that the bo is not published to userspace<br /> until later, so not sure what the comment "Don&amp;#39;t publish the bo<br /> until we have a valid attachment", is referring to.<br /> <br /> We have at least two different customers reporting hitting a NULL ptr<br /> deref in evict_flags when importing something from amdgpu, followed by<br /> triggering the evict flow. Hit rate is also pretty low, which would<br /> hint at some kind of race, so something like 1) or 2) might explain<br /> this.<br /> <br /> v2:<br /> - Shuffle the order of the ops slightly (no functional change)<br /> - Improve the comment to better explain the ordering (Matt B)<br /> <br /> (cherry picked from commit af1f2ad0c59fe4e2f924c526f66e968289d77971)