workflows.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jiri Kosina <jikos@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	corbet@lwn.net,  workflows@vger.kernel.org,
	linux-doc@vger.kernel.org,  linux-kernel@vger.kernel.org,
	security@kernel.org,  Kees Cook <keescook@chromium.org>,
	Sasha Levin <sashal@kernel.org>,  Lee Jones <lee@kernel.org>
Subject: Re: [PATCH v3] Documentation: Document the Linux Kernel CVE process
Date: Wed, 14 Feb 2024 15:46:12 +0100 (CET)	[thread overview]
Message-ID: <nycvar.YFH.7.76.2402141539180.21798@cbobk.fhfr.pm> (raw)
In-Reply-To: <7c177ba2-6b0a-4203-9ee6-113e75c6bb13@sirena.org.uk>

On Wed, 14 Feb 2024, Mark Brown wrote:

> Not addressing your point in general but the speaker volume limiting is
> security relevant, that change prevents physical damage to the system.
> There's an argument for many headphone volume related fixes too since
> excessively large volumes can cause substantial distress and potential
> injury to users (I can't remember if that fix would be relevant to that
> issue).

Thanks, I guess you are actually supporting my point, and that is -- there 
is no consensus whatsoever of what assigning a CVE actually means, at all.

To me -- physical damage to the system, fair enough, that might really 
easily be security relevant.

Something being too loud, causing distress ... that's really a grey zone 
(to put it mildly) for me. How about e.g. a bug in GPU driver, leading to 
a flickering screen? Many people are very sensitive to that (both 
physically and mentally) for various reasons.

Bug worth fixing? Absolutely, as soon as possible. Security-relevant? Not 
in my book.

To me, kernel is in no way special, in this respect, actually. With each 
and every coding error in software of your choice, given anough fantasy, 
you'll come up with a scenario where this will cause some real issues to 
some living human.

That's not what CVE is about at all, at least in my understaing.

-- 
Jiri Kosina
SUSE Labs


  parent reply	other threads:[~2024-02-14 14:46 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-14  8:00 Greg Kroah-Hartman
2024-02-14  8:34 ` Lukas Bulwahn
2024-02-15 12:04   ` Greg Kroah-Hartman
2024-02-15 16:10     ` Oleksandr Natalenko
2024-02-15 17:49       ` Greg Kroah-Hartman
2024-02-14  8:37 ` Vegard Nossum
2024-02-15 11:50   ` Greg Kroah-Hartman
2024-02-15 12:24     ` Vegard Nossum
2024-02-16  8:28       ` Jani Nikula
2024-02-16 11:22         ` Greg Kroah-Hartman
2024-02-16 14:58           ` Jonathan Corbet
2024-02-17 11:56             ` Greg Kroah-Hartman
2024-02-14 13:10 ` Krzysztof Kozlowski
2024-02-15 12:00   ` Greg Kroah-Hartman
2024-02-14 13:41 ` Konstantin Ryabitsev
2024-02-15 11:59   ` Greg Kroah-Hartman
2024-02-14 13:43 ` Jiri Kosina
2024-02-14 13:55   ` Mark Brown
2024-02-14 14:32     ` Greg Kroah-Hartman
2024-02-14 14:46     ` Jiri Kosina [this message]
2024-02-14 15:10       ` Mark Brown
2024-02-14 13:58   ` Greg Kroah-Hartman
2024-02-14 14:38     ` Jiri Kosina
2024-02-14 15:09       ` Greg Kroah-Hartman
2024-02-15  8:17 ` Thorsten Leemhuis
2024-02-15  8:43   ` Greg Kroah-Hartman
2024-02-15 17:54 ` Michal Hocko
2024-02-15 18:20   ` Greg Kroah-Hartman
2024-02-15 18:36     ` Michal Hocko
2024-02-16 11:25       ` Greg Kroah-Hartman
2024-02-16 13:20         ` Michal Hocko
2024-02-16 15:34           ` Greg Kroah-Hartman
2024-02-16 16:51             ` Michal Hocko
2024-02-15 19:40     ` Kees Cook
2024-02-16  7:41       ` 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=nycvar.YFH.7.76.2402141539180.21798@cbobk.fhfr.pm \
    --to=jikos@kernel.org \
    --cc=broonie@kernel.org \
    --cc=corbet@lwn.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=keescook@chromium.org \
    --cc=lee@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sashal@kernel.org \
    --cc=security@kernel.org \
    --cc=workflows@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox