From: Jani Nikula <jani.nikula@linux.intel.com>
To: Zilin Guan <zilin@seu.edu.cn>, maarten.lankhorst@linux.intel.com
Cc: mripard@kernel.org, tzimmermann@suse.de, airlied@gmail.com,
simona@ffwll.ch, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, jianhao.xu@seu.edu.cn,
Zilin Guan <zilin@seu.edu.cn>
Subject: Re: [PATCH] drm: Use kvmemdup/kvfree for EDID data
Date: Mon, 08 Sep 2025 16:54:35 +0300 [thread overview]
Message-ID: <2040b1e245eb0166079ff985c52775e9ade9eab5@intel.com> (raw)
In-Reply-To: <20250905151156.844758-1-zilin@seu.edu.cn>
On Fri, 05 Sep 2025, Zilin Guan <zilin@seu.edu.cn> wrote:
> The drm_edid_alloc() function uses kmemdup() to copy raw EDID data,
> which can be loaded from firmware. A problem exists because the firmware
> subsystem uses vfree() to release its data buffer. This implies the
> buffer may be allocated with vmalloc() and can thus be larger than
> kmalloc() typically supports. Since kmemdup() uses kmalloc() internally,
> attempting to duplicate a large, vmalloc'd EDID buffer can lead to an
> allocation failure.
Real world EDIDs are usually under 1 kB and if the user provides a much
bigger EDID via the firmware loader it's okay to fail at the allocation
time.
BR,
Jani.
>
> To fix this mismatch and robustly handle EDID data of any size, this
> patch replaces kmemdup() with kvmemdup(). The kvmemdup() function is
> designed for this scenario, as it can safely handle a vmalloc'd source
> and choose an appropriate allocator for the destination. The corresponding
> free calls are therefore updated to kvfree().
>
> Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
> ---
> drivers/gpu/drm/drm_edid.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index e2e85345aa9a..97142bfc45ad 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2530,13 +2530,13 @@ const struct drm_edid *drm_edid_alloc(const void *edid, size_t size)
> if (!edid || !size || size < EDID_LENGTH)
> return NULL;
>
> - edid = kmemdup(edid, size, GFP_KERNEL);
> + edid = kvmemdup(edid, size, GFP_KERNEL);
> if (!edid)
> return NULL;
>
> drm_edid = _drm_edid_alloc(edid, size);
> if (!drm_edid)
> - kfree(edid);
> + kvfree(edid);
>
> return drm_edid;
> }
> @@ -2568,7 +2568,7 @@ void drm_edid_free(const struct drm_edid *drm_edid)
> if (!drm_edid)
> return;
>
> - kfree(drm_edid->edid);
> + kvfree(drm_edid->edid);
> kfree(drm_edid);
> }
> EXPORT_SYMBOL(drm_edid_free);
--
Jani Nikula, Intel
prev parent reply other threads:[~2025-09-08 13:54 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-05 15:11 Zilin Guan
2025-09-08 13:54 ` Jani Nikula [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2040b1e245eb0166079ff985c52775e9ade9eab5@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=airlied@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jianhao.xu@seu.edu.cn \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=simona@ffwll.ch \
--cc=tzimmermann@suse.de \
--cc=zilin@seu.edu.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®