drm/gud: fix out-of-bounds write in gud_plane_atomic_check()
Subsystems (3)
PATCH 1/1 drm/gud: fix out-of-bounds write in gud_plane_atomic_check()
The plane property loop uses req->properties[num_properties + i] as write index while simultaneously incrementing num_properties inside the loop. At iteration i, num_properties has also incremented by i, so the write is done at initial_num_properties + 2*i, skipping every other index and advancing by 2 per iteration.
With just 2 connector and 32 plane properties the last write happens at index 64, one slot past the end of the 64-slot (indices 0–63) allocation. A USB device can trigger OOB by advertising the maximum number of properties.
Fix by dropping the redundant + i; num_properties is already the correct running index, as gud_connector_fill_properties() fills the preceding slots.
---
Verified with KASAN using a raw-gadget fake GUD device reporting 2 connector properties and 32 plane properties:
BUG: KASAN: slab-out-of-bounds in gud_plane_atomic_check+0x1352/0x1ba0 Write of size 2 at addr ffff88800d029a9a by task temm/270 Call Trace: <TASK> kasan_report+0xfa/0x120 gud_plane_atomic_check+0x1352/0x1ba0 drm_atomic_helper_check_planes+0x2f2/0x9b0 drm_atomic_helper_check+0x72/0x140 drm_atomic_check_only+0x127b/0x3420 drm_atomic_commit+0x124/0x2e0 drm_atomic_helper_set_config+0xd9/0x130 drm_mode_setcrtc+0xcfd/0x1b20 drm_ioctl_kernel+0x167/0x2d0 drm_ioctl+0x53f/0xbe0 __x64_sys_ioctl+0x137/0x1c0 do_syscall_64+0xde/0x4b0 </TASK>
The buggy address is located 0 bytes to the right of allocated 666-byte region [ffff88800d029800, ffff88800d029a9a)
drivers/gpu/drm/gud/gud_pipe.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/gud/gud_pipe.c +2 -2
@@ -562,8 +562,8 @@ int gud_plane_atomic_check(struct drm_plane *plane, goto out; } - req->properties[num_properties + i].prop =cpu_to_le16 (prop); - req->properties[num_properties + i].val =cpu_to_le64 (val); + req->properties[num_properties].prop =cpu_to_le16 (prop); + req->properties[num_properties].val =cpu_to_le64 (val); num_properties++; }
--
2.55.0
[email protected]
AI reviewThank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Use-After-Free due to unsafe access to connector->state in the fallback logic without proper locking or addition to the atomic state.
- [Medium] Iterator variable connector_state leaks from the for_each_new_connector_in_state loop when no CRTC-bound connector is found, causing the wrong connector state to be used. --
commit 0c2e0cfd22b820fc8dacf39a623bb3f5f21ff275
Author: Sajal Gupta <[email protected]>
drm/gud: fix out-of-bounds write in gud_plane_atomic_check()
This commit fixes an out-of-bounds write in the plane property loop of gud_plane_atomic_check(). It drops a redundant addition of the loop index to num_properties, since num_properties is already the correct running index.
Quoted 4 lines
drivers/gpu/drm/gud/gud_pipe.c +0
-0
[ ... ]
drivers/gpu/drm/gud/gud_pipe.c int gud_plane_atomic_check(struct drm_plane *plane, · line 568
Quoted 10 lines
drivers/gpu/drm/gud/gud_pipe.c +2
-2@@ -562,8 +562,8 @@ int gud_plane_atomic_check(struct drm_plane *plane, goto out; } - req->properties[num_properties + i].prop =cpu_to_le16 (prop); - req->properties[num_properties + i].val =cpu_to_le64 (val); + req->properties[num_properties].prop =cpu_to_le16 (prop); + req->properties[num_properties].val =cpu_to_le64 (val); num_properties++; }
While reviewing this change, I noticed a couple of pre-existing issues earlier in gud_plane_atomic_check():
drivers/gpu/drm/gud/gud_pipe.c:gud_plane_atomic_check() {
...
for_each_new_connector_in_state(state, connector, connector_state, i) {
if (connector_state->crtc)
break;
}
/*
* DRM_IOCTL_MODE_OBJ_SETPROPERTY on the rotation property will not have
* the connector included in the state.
*/
if (!connector_state) {[Severity: Medium]
This is a pre-existing issue, but I noticed the iterator variable connector_state is not cleared if the loop completes without hitting the break statement.
If userspace submits an atomic commit updating a plane property while simultaneously modifying a disconnected connector, the loop evaluates the disconnected connector and finishes without breaking. This leaves connector_state retaining the disconnected state.
Since connector_state is no longer NULL, the fallback check is skipped. Could this cause the hardware check command GUD_REQ_SET_STATE_CHECK to receive the ID of a disconnected connector and misconfigure the display?
struct drm_connector_list_iter conn_iter;
drm_connector_list_iter_begin(plane->dev, &conn_iter);
drm_for_each_connector_iter(connector, &conn_iter) {
if (connector->state->crtc) {
connector_state = connector->state;
break;
}
}
drm_connector_list_iter_end(&conn_iter);
}[Severity: High]
This is also a pre-existing issue, but does this fallback logic risk a use-after-free by directly accessing connector->state?
When an atomic commit updates only a plane property, the fallback logic iterates all system connectors and directly assigns connector_state to connector->state. Because the connector is not added to the atomic state via drm_atomic_get_connector_state(), its lock is not held by the current thread.
If a concurrent userspace thread issues a property update on this connector, could it swap and free the old state while gud_connector_fill_properties() is simultaneously reading from it?
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
Quoted 11 lines · Sajal Gupta
The plane property loop uses req->properties[num_properties + i] as write index while simultaneously incrementing
num_propertiesinside the loop. At iteration i,num_propertieshas also incremented by i, so the write is done atinitial_num_properties + 2*i, skipping every other index and advancing by 2 per iteration.With just 2 connector and 32 plane properties the last write happens at index 64, one slot past the end of the 64-slot (indices 0–63) allocation. A USB device can trigger OOB by advertising the maximum number of properties.
Quoted 8 lines
Fix by dropping the redundant
+ i;num_propertiesis already the correct running index, asgud_connector_fill_properties()fills the preceding slots.Fixes 40e1a70b4aed ("drm: Add GUD USB Display driver")Reported-by Sashiko <[email protected]>Signed-off-by Sajal Gupta <[email protected]>
Sorry, for some reason I didn't receive this patch in my mailbox, only by manually searching for patches did I find it, thanks for the patch.
Quoted 48 lines
---
Verified with KASAN using a raw-gadget fake GUD device reporting 2 connector properties and 32 plane properties:
BUG: KASAN: slab-out-of-bounds in gud_plane_atomic_check+0x1352/0x1ba0 Write of size 2 at addr ffff88800d029a9a by task temm/270 Call Trace: <TASK> kasan_report+0xfa/0x120 gud_plane_atomic_check+0x1352/0x1ba0 drm_atomic_helper_check_planes+0x2f2/0x9b0 drm_atomic_helper_check+0x72/0x140 drm_atomic_check_only+0x127b/0x3420 drm_atomic_commit+0x124/0x2e0 drm_atomic_helper_set_config+0xd9/0x130 drm_mode_setcrtc+0xcfd/0x1b20 drm_ioctl_kernel+0x167/0x2d0 drm_ioctl+0x53f/0xbe0 __x64_sys_ioctl+0x137/0x1c0 do_syscall_64+0xde/0x4b0 </TASK>The buggy address is located 0 bytes to the right of allocated 666-byte region [
ffff88800d029800,ffff88800d029a9a)drivers/gpu/drm/gud/gud_pipe.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)drivers/gpu/drm/gud/gud_pipe.c +2
-3@@ -562,8 +562,8 @@ int gud_plane_atomic_check(struct drm_plane *plane, goto out; } - req->properties[num_properties + i].prop =cpu_to_le16 (prop); - req->properties[num_properties + i].val =cpu_to_le64 (val); + req->properties[num_properties].prop =cpu_to_le16 (prop); + req->properties[num_properties].val =cpu_to_le64 (val); num_properties++; } --2.55.0