public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Ben Hutchings <benh@debian.org>
Cc: Sasha Levin <sashal@kernel.org>, stable <stable@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	linux-scsi <linux-scsi@vger.kernel.org>,
	security@kernel.org
Subject: Re: dpt_i2o fixes for stable
Date: Sun, 28 May 2023 14:59:18 +0100	[thread overview]
Message-ID: <2023052856-starfish-avoid-3dde@gregkh> (raw)
In-Reply-To: <5eb8dad50ac455513be8c93c2f0aa0b5b9627b3e.camel@debian.org>

On Sun, May 28, 2023 at 02:40:52PM +0200, Ben Hutchings wrote:
> On Sun, 2023-05-28 at 08:02 +0100, Greg Kroah-Hartman wrote:
> > On Sat, May 27, 2023 at 10:42:00PM +0200, Ben Hutchings wrote:
> > > I'm proposing to address the most obvious issues with dpt_i2o on stable
> > > branches.  At this stage it may be better to remove it as has been done
> > > upstream, but I'd rather limit the regression for anyone still using
> > > the hardware.
> > > 
> > > The changes are:
> > > 
> > > - "scsi: dpt_i2o: Remove broken pass-through ioctl (I2OUSERCMD)",
> > >   which closes security flaws including CVE-2023-2007.
> > > - "scsi: dpt_i2o: Do not process completions with invalid addresses",
> > >   which removes the remaining bus_to_virt() call and may slightly
> > >   improve handling of misbehaving hardware.
> > > 
> > > These changes have been compiled on all the relevant stable branches,
> > > but I don't have hardware to test on.
> > 
> > Why don't we just delete it in the stable trees as well?  If no one has
> > the hardware (otherwise the driver would not have been removed), who is
> > going to hit these issues anyway?
> 
> We don't know that no-one is using the hardware, just because no-one
> among a small group of kernel developers and early adopters has spoken
> up yet.

So what are we supposed to do here.  Take patches that even if the
driver is added back upstream will not get merged there (as it will not
be obvious they are needed)?  Or just ignore this?

Why did you work on these changes, were there reports of problems?  Or
complaints from users?  Something else?

thanks,

greg k-h

  reply	other threads:[~2023-05-28 14:01 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-27 20:42 dpt_i2o fixes for stable Ben Hutchings
2023-05-28  7:02 ` Greg Kroah-Hartman
2023-05-28  9:58   ` Finn Thain
2023-05-28 11:28     ` Greg Kroah-Hartman
2023-05-29  0:06       ` Finn Thain
2023-05-28 12:40   ` Ben Hutchings
2023-05-28 13:59     ` Greg Kroah-Hartman [this message]
2023-05-29  0:29       ` Finn Thain
2023-06-07 18:00 ` 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=2023052856-starfish-avoid-3dde@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=arnd@arndb.de \
    --cc=benh@debian.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=sashal@kernel.org \
    --cc=security@kernel.org \
    --cc=stable@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