Claude review: drm/gem: Fix inconsistent plane dimension calculation in drm_gem_fb_init_with_funcs()

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

**Code correctness: Good.** The change from:
```c
unsigned int width = mode_cmd->width / (i ? info->hsub : 1);
unsigned int height = mode_cmd->height / (i ? info->vsub : 1);
```
to:
```c
unsigned int width = drm_format_info_plane_width(info, mode_cmd->width, i);
unsigned int height = drm_format_info_plane_height(info, mode_cmd->height, i);
```

is correct. Looking at the helper definitions in `include/drm/drm_fourcc.h:272-305`, for `plane == 0` they return the original value (matching the old `(i ? ... : 1)` logic), and for `plane > 0` they use `DIV_ROUND_UP()` instead of truncating division. This matches what `framebuffer_check()` does at `drm_framebuffer.c:172-173`.

**Bug analysis is accurate.** The concrete scenario described — NV12 (vsub=2), height=1 — is a valid reproduction case:
- `framebuffer_check()` computes chroma height = `DIV_ROUND_UP(1, 2) = 1`, passes validation
- Old `drm_gem_fb_init_with_funcs()` computes chroma height = `1 / 2 = 0`
- `min_size = (0 - 1) * pitches[i] + ...` wraps `(unsigned int)(0 - 1)` = `0xFFFFFFFF`
- The multiply + add overflows `unsigned int`, potentially yielding a small `min_size`
- A too-small GEM object passes the size guard

**Issues to address:**

1. **Missing `Fixes:` tag.** This is a bug fix and should include a `Fixes:` tag referencing the commit that introduced this code (likely the original `drm_gem_fb_init_with_funcs()` or a refactor that introduced the open-coded division). This is important for backporting decisions.

2. **Missing `Cc: stable@vger.kernel.org`.** Given this is a potential out-of-bounds access triggered from userspace (via the `DRM_IOCTL_MODE_ADDFB2` path), this should be tagged for stable backports.

3. **Minor type mismatch.** `drm_format_info_plane_width()` and `drm_format_info_plane_height()` return `int`, but the local variables are `unsigned int`. This is a pre-existing pattern (the same implicit conversion happens at `drm_framebuffer.c:172-173`), so it's not introduced by this patch — but worth noting. The values will always be positive in practice since `framebuffer_check()` rejects `width==0` and `height==0` before this code runs.

4. **Commit message quality.** The commit message is well written and clearly explains the root cause, the concrete failure scenario, and the fix. No issues here.

**Summary:** The code change is correct, minimal, and addresses a real bug that could allow a malicious userspace to bypass the GEM object size check for sub-sampled formats. It should be resubmitted with `Fixes:` and `Cc: stable` tags added.

---
Generated by Claude Code Patch Reviewer