From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: fbdev: omap2: fix use-after-free in omapfb_mmap Date: Thu, 04 Jun 2026 13:04:18 +1000 Message-ID: In-Reply-To: <20260602085421.194325-1-zenghongling@kylinos.cn> References: <20260602085421.194325-1-zenghongling@kylinos.cn> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Overall Series Review Subject: fbdev: omap2: fix use-after-free in omapfb_mmap Author: Hongling Zeng Patches: 1 Reviewed: 2026-06-04T13:04:18.710868 --- This is a single-patch series fixing a race condition between `omapfb_mmap(= )` and `OMAPFB_SETUP_PLANE` ioctl in the omap2 fbdev driver. The race analy= sis in the commit message is sound =E2=80=94 `ofbi->region` can be reassign= ed concurrently, causing `omapfb_get_region_paddr()` to read from the new r= egion while `map_count` is incremented on the old one, enabling a use-after= -free. However, the patch has a **critical bug**: it adds a new `atomic_inc(&rg->m= ap_count)` before `vm_iomap_memory()` without removing the original increme= nt after it. This double-increments `map_count` on the success path, leakin= g a reference and preventing the region from ever being freed. Additionally, the commit message claims to fix the race on both `start` and= `len`, but `len` is still read from the raceable `fix->smem_len`. **Recommendation: Needs revision.** The double-increment must be fixed befo= re this can be applied. --- --- Generated by Claude Code Patch Reviewer