From: Dan Carpenter <error27@gmail.com>
To: Marinela Tatiana Selseth <marinela.selseth@firmwaredesign.org>
Cc: gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
linux-staging@lists.linux.dev
Subject: Re: [PATCH] staging: vme_user: fix list iterator tracking and prune dead validations
Date: Thu, 15 Oct 2026 12:16:12 +0300 [thread overview]
Message-ID: <atCZ3PvVh6kzaGql@stanley.mountain> (raw)
In-Reply-To: <20261005042911.64922-1-marinela.selseth@firmwaredesign.org>
On Sun, Oct 04, 2026 at 11:29:11PM -0500, Marinela Tatiana Selseth wrote:
> Automated static analysis runs using 'make coccicheck' uncovered
> multiple critical logic and validation flaws inside the VME subsystem.
> The file drivers/staging/vme_user/vme.c contained repetitive
> unreachable checks testing list iterator pointers for NULL (such as if
> (!dma_ctrlr) and if (!lm)) immediately following 'list_for_each_entry'
> loop boundaries.
> Because of internal pointer arithmetic designs, these loop variables
> are mathematically guaranteed to never evaluate to NULL during loop
> processing.
>
> Worse, if memory allocations failed for the corresponding structure
> images, the error cleanup paths ('err_alloc:') attempted to acquire
> spinlocks or mutex blocks using those same loop iterators. Since the
> traversal was already complete, these pointers held out-of-bounds,
> scrambled memory offsets, exposing the kernel to critical Null Pointer
> Dereference panics.
AI write too long wordy commit messages. This second paragraph is
also wrong factually.
1. The check:
/* Check to see if we found a resource */
if (!allocated_image) {
ensures that we hit a break and the pointer is valid.
2. It wouldn't be a NULL pointer dereference, it would be an
invalid pointer.
>
> Clean up this driver architecture by removing the unreachable loop
> checks entirely, dropping stale, misleading warning statements, and
> routing the post-loop lock cleanups cleanly through verified
> allocation tracking pointer references.
>
> Assisted-by: Gemini
> Signed-off-by: Marinela Tatiana Selseth <marinela.selseth@firmwaredesign.org>
> ---
If the bug were real as stated in the commit message then we would
need a Fixes tag.
regards,
dan carpenter
prev parent reply other threads:[~2026-10-15 9:16 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-05 4:29 [PATCH] staging: vme_user: fix list iterator tracking and prune dead validations Marinela Tatiana Selseth
2026-10-15 9:16 ` Dan Carpenter [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=atCZ3PvVh6kzaGql@stanley.mountain \
--to=error27@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=marinela.selseth@firmwaredesign.org \
/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.