• File: sys/dev/drm/radeon/radeon_fb.c
• Lines: 224, 230–238, 149, 257
• Severity: Info
• CVSS 3.1: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N
• CWE: CWE-457 Use of Uninitialized Variable
• Confidence: likely
• Status: new

Summary

struct drm_mode_fb_cmd2 mode_cmd; (radeon_fb.c:224) is declared without an initializer. Only width (230), height (231), pixel_format (237-238), and pitches[0] (set inside radeonfb_create_pinned_object at radeon_fb.c:149) are written. The remaining fields — pitches[1..3], offsets[0..3], modifier[0], flags, handles[0..3] — stay as stack garbage and are copied verbatim into the long-lived drm_framebuffer by drm_helper_mode_fill_fb_struct (invoked via radeon_framebuffer_init at radeon_display.c:1302; copies at drm_modeset_helper.c:88-92).

Root cause

radeon_fb.c:224 struct drm_mode_fb_cmd2 mode_cmd; — no = {} or memset. Writes are partial: - radeon_fb.c:230-231 (width, height) - radeon_fb.c:237-238 (pixel_format) - radeon_fb.c:149 (pitches[0] only)

drm_helper_mode_fill_fb_struct then does for (i = 0; i < 4; i++) { fb->pitches[i] = mode_cmd->pitches[i]; fb->offsets[i] = mode_cmd->offsets[i]; } and fb->modifier = mode_cmd->modifier[0]; fb->flags = mode_cmd->flags; (drm_modeset_helper.c:87-92), copying uninitialized stack into the persistent framebuffer object.

Threat model

For single-plane legacy formats (the only kind drm_mode_legacy_fb_format produces, radeon_fb.c:237), pitches[1..3]/offsets/num_planes=1 so the garbage is never read by scanout logic — dead data in practice.

The garbage does, however, persist in a kernel object whose lifetime equals the framebuffer's and could be read back via DRM ioctls that walk fb metadata (info leak of kernel-stack contents into long-lived state).

The most plausible real impact is a future code path that starts consulting fb->modifier or fb->flags and misbehaves on garbage (e.g., tiling modifier that happens to look like DRM_FORMAT_MOD_LINEAR). No current reader in the radeon driver consults fb->modifier.

Proof of concept

Trigger radeon_fbdev_init on boot (automatic with a radeon GPU attached). Then use a DRM ioctl to read fb metadata — DRM_IOCTL_MODE_GETFB2 — and observe that fb->modifier / fb->flags / fb->offsets[1..3] / fb->pitches[1..3] contain stack bytes from the radeonfb_create call frame.

Because the framebuffer is the boot fbcon object, this is reachable from any user with O_RDWR on /dev/dri/card0. Concrete leak rate is low (a handful of u32 fields, fixed for the lifetime of the fb).

Recommended fix

Zero-initialize mode_cmd.

--- a/sys/dev/drm/radeon/radeon_fb.c
+++ b/sys/dev/drm/radeon/radeon_fb.c
@@ -221,7 +221,7 @@ static int radeonfb_create(struct drm_fb_helper *helper,
    struct radeon_fbdev *rfbdev =
        container_of(helper, struct radeon_fbdev, helper);
    struct radeon_device *rdev = rfbdev->rdev;
-   struct fb_info *info;
+   struct fb_info *info;
    struct drm_framebuffer *fb = NULL;
-   struct drm_mode_fb_cmd2 mode_cmd;
+   struct drm_mode_fb_cmd2 mode_cmd = { 0 };
    struct drm_gem_object *gobj = NULL;

References

• sys/dev/drm/radeon/radeon_fb.c:224,230-238,149 — partial initialization
• sys/dev/drm/radeon/radeon_display.c:1302 — calls drm_helper_mode_fill_fb_struct
• sys/dev/drm/drm_modeset_helper.c:87-92 — copies all fields verbatim into long-lived fb