All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Petr Mladek <pmladek@suse.com>
Cc: cve@kernel.org, linux-kernel@vger.kernel.org,
	linux-cve-announce@vger.kernel.org,
	"Srikar Dronamraju" <srikar@linux.vnet.ibm.com>,
	"Nicholas Piggin" <npiggin@gmail.com>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	"Tejun Heo" <tj@kernel.org>, "Sasha Levin" <sashal@kernel.org>,
	"Michal Hocko" <mhocko@suse.com>,
	"Michal Koutný" <mkoutny@suse.com>
Subject: Re: CVE-2024-46839: workqueue: Improve scalability of workqueue watchdog touch
Date: Tue, 1 Oct 2024 10:22:51 +0200	[thread overview]
Message-ID: <2024100116-shaky-iguana-7f54@gregkh> (raw)
In-Reply-To: <ZvusWymx4rGO55NG@pathway.suse.cz>

On Tue, Oct 01, 2024 at 10:02:02AM +0200, Petr Mladek wrote:
> On Fri 2024-09-27 14:40:07, Greg Kroah-Hartman wrote:
> > Description
> > ===========
> > 
> > In the Linux kernel, the following vulnerability has been resolved:
> > 
> > workqueue: Improve scalability of workqueue watchdog touch
> > 
> > On a ~2000 CPU powerpc system, hard lockups have been observed in the
> > workqueue code when stop_machine runs (in this case due to CPU hotplug).
> 
> I believe that this does not qualify as a security vulnerability.
> Any hotplug is a privileged operation.

Really?  I see that happen on many embedded systems all the time, they
add/remove CPUs while the device runs/sleeps constantly.

Now to be fair, right now an "embedded system" usually doesn't have 2000
cpus, but what's wrong with marking this real bugfix as a vulnerability
resolution?  If you don't run your system in a way that allows cpus to
be stopped unless an admin says so, it will not be relevant.

thanks,

greg k-h

  reply	other threads:[~2024-10-01  8:23 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-27 12:40 CVE-2024-46839: workqueue: Improve scalability of workqueue watchdog touch Greg Kroah-Hartman
2024-10-01  8:02 ` Petr Mladek
2024-10-01  8:22   ` Greg Kroah-Hartman [this message]
2024-10-01  9:07     ` Michal Hocko
2024-10-01 11:37       ` Paul E. McKenney
2024-10-01 13:53       ` Greg Kroah-Hartman

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=2024100116-shaky-iguana-7f54@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=cve@kernel.org \
    --cc=linux-cve-announce@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhocko@suse.com \
    --cc=mkoutny@suse.com \
    --cc=npiggin@gmail.com \
    --cc=paulmck@kernel.org \
    --cc=pmladek@suse.com \
    --cc=sashal@kernel.org \
    --cc=srikar@linux.vnet.ibm.com \
    --cc=tj@kernel.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.