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: efifb: fix memory leak in efifb_probe() Date: Sat, 16 May 2026 11:10:42 +1000 Message-ID: In-Reply-To: <20260514-fbdev-v1-12-b3a2474fa720@cse.iitm.ac.in> References: <20260514-fbdev-v1-0-b3a2474fa720@cse.iitm.ac.in> <20260514-fbdev-v1-12-b3a2474fa720@cse.iitm.ac.in> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Patch Review **Status: Correct, but needs verification of the Fixes claim** ```c efifb_setup(si, option); +kfree(option); ``` I verified that `fb_get_options()` calls `kstrdup()` to duplicate the optio= n string, giving ownership to the caller. I also verified that `efifb_setup= ()` passes `options` by value to `strsep()`, which modifies only the local = copy of the pointer =E2=80=94 the caller's `option` variable still points t= o the start of the allocated buffer. So `kfree(option)` is safe. The key question is whether the referenced commit `73ce73c30ba9` actually c= hanged `fb_get_options()` to use `kstrdup()`. The current code in `fb_cmdli= ne.c` does indeed use `kstrdup()` with a comment saying "The caller owns th= e string returned in @option and is responsible for releasing the memory." = This confirms the fix is correct. Note this does NOT leak on the `fb_get_options()` failure path since that r= eturns `-ENODEV` before reaching the `kfree`. --- --- Generated by Claude Code Patch Reviewer