Linux EDAC development
 help / color / mirror / Atom feed
From: Robert Richter <rric@kernel.org>
To: Borislav Petkov <bp@alien8.de>
Cc: Ian Bridges <icb@fastmail.org>, Tony Luck <tony.luck@intel.com>,
	linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-hardening@vger.kernel.org
Subject: Re: [PATCH] EDAC/thunderx: Replace strlcat() with snprintf() and seq_buf
Date: Mon, 10 Aug 2026 15:27:12 +0200	[thread overview]
Message-ID: <annRsN6UBDPsFLr2@rric.localdomain> (raw)
In-Reply-To: <20260729230035.GDamqGE9bKD5ncU6ZV@fat_crate.local>

On 29.07.26 16:00:35, Borislav Petkov wrote:
> On Wed, Jul 29, 2026 at 03:57:14PM -0500, Ian Bridges wrote:
> > On Thu, Jul 02, 2026 at 01:46:45AM -0500, Ian Bridges wrote:
> > Gentle ping. This patch has had no response since it was posted on
> > July 2. The code it converts is unchanged on ras.git edac-for-next
> > as of this week, and the patch still applies cleanly. Happy to
> > resend if that is easier.
> 
> Are you in a hurry with this or is there anything that needs immediate
> handling?
> 
> And I obviously can't apply untested patches.
> 
> Also, I see you've CCed the maintainer of that driver so he should probably
> take a look.
> 
> And talking about maintainers, Sashiko points out a bunch of previous issues
> with this driver:
> 
> https://sashiko.dev/#/patchset/akYJUdY1hVABUQH6%40dev
> 
> so, Robert, what's the story here, are we still caring for this or can I mark
> it obsolete and drop it?

The driver issues found by Sashiko are valid, the return parameter of
snprintf is wrongly used and may cause buffer overflows.

Regarding the mem barrier: On a first glance, it might not be needed
here as this runs in the irq handler. That is, there is no concurrent
handler and code will not be rescheduled to another cpu. But still,
that should be checked in detail.

However, the driver has several issues. I asked Marvell a while ago to
take over maintainership, but never got a response. I don't have
hardware to test changes. If you mean to mark the driver obsolete, I
am good with it. On the other hand, the issues found may not actually
trigger and only affect a single system. If we can live with it, we
could leave it as is.

Thanks,

-Robert

  parent reply	other threads:[~2026-08-10 13:27 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-02  6:46 [PATCH] EDAC/thunderx: Replace strlcat() with snprintf() and seq_buf Ian Bridges
2026-07-29 20:57 ` Ian Bridges
2026-07-29 23:00   ` Borislav Petkov
2026-07-30  2:35     ` Ian Bridges
2026-07-30  4:57       ` Borislav Petkov
2026-08-10 13:27     ` Robert Richter [this message]
2026-08-10 13:45       ` Borislav Petkov
2026-08-10 21:16         ` Robert Richter
2026-08-11  0:59           ` Borislav Petkov

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=annRsN6UBDPsFLr2@rric.localdomain \
    --to=rric@kernel.org \
    --cc=bp@alien8.de \
    --cc=icb@fastmail.org \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tony.luck@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox