From: Andi Shyti <andi.shyti@kernel.org>
To: Krzysztof Karas <krzysztof.karas@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
Andi Shyti <andi.shyti@linux.intel.com>,
Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>,
Sebastian Brzezinka <sebastian.brzezinka@intel.com>,
Krzysztof Niemiec <krzysztof.niemiec@intel.com>
Subject: Re: [PATCH] drm/i915/gem: Prevent overstepping exec array boundary
Date: Wed, 30 Sep 2026 02:54:02 +0200 [thread overview]
Message-ID: <arxdlg12dVFOAI2P@zenone.zhora.eu> (raw)
In-Reply-To: <20260911061145.3535489-1-krzysztof.karas@intel.com>
Hi Krzysztof,
On Fri, Sep 11, 2026 at 06:11:45AM +0000, Krzysztof Karas wrote:
> It is possible for eb_relocate_parse_slow() to call kvfree() on
> entries outside the original exec array during following
> scenario inside eb_relocate_parse_slow():
>
> 1) eb_copy_relocations() allocates as many as eb->buffer_count
> copies for exec entries;
> 2) eb_parse() appends up to two VMAs, right after incrementing
> eb->buffer_count;
> 3) cleanup under "out" label uses this incremented buffer_count
> to release relocation pointers from exec array via kvfree(),
> not from VMA array.
>
> To amend this problem, ensure that relocation cleanup uses the
> original exec object count, excluding the VMAs appended by the
> command parser.
>
> Fixes: 8e4ba491b0ba ("drm/i915: Parse command buffer earlier in eb_relocate(slow)")
> Cc: stable@vger.kernel.org # 5.10+
> Assisted-by: GitHub-Copilot:gpt-6-astra
> Signed-off-by: Krzysztof Karas <krzysztof.karas@intel.com>
pushed to drm-intel-gt-next.
Thanks,
Andi
next prev parent reply other threads:[~2026-09-30 0:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-11 6:11 [PATCH] drm/i915/gem: Prevent overstepping exec array boundary Krzysztof Karas
2026-09-11 6:29 ` sashiko-bot
2026-09-11 7:04 ` ✓ i915.CI.BAT: success for " Patchwork
2026-09-12 3:05 ` ✗ i915.CI.Full: failure " Patchwork
2026-09-30 0:54 ` Andi Shyti [this message]
2026-09-30 5:57 ` [PATCH] " Krzysztof Karas
2026-10-04 14:09 ` linux-kernel
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=arxdlg12dVFOAI2P@zenone.zhora.eu \
--to=andi.shyti@kernel.org \
--cc=andi.shyti@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=janusz.krzysztofik@linux.intel.com \
--cc=krzysztof.karas@intel.com \
--cc=krzysztof.niemiec@intel.com \
--cc=sebastian.brzezinka@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.