linux-kernel - Re: [char-misc-next v3] mei: use kvmalloc for read buffer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CA+i0qc7JgJucJeQ=oagCu932JmuTZ1-LBUhgCukzn7XPaCMfxw@mail.gmail.com>
Date: Mon, 21 Oct 2024 18:49:02 +0300
From: Tomas Winkler <tomasw@...il.com>
To: Brian Geffon <bgeffon@...gle.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, 
	Alexander Usyskin <alexander.usyskin@...el.com>, Oren Weil <oren.jer.weil@...el.com>, 
	linux-kernel@...r.kernel.org, stable@...r.kernel.org, 
	Rohit Agarwal <rohiagar@...omium.org>
Subject: Re: [char-misc-next v3] mei: use kvmalloc for read buffer

On Mon, Oct 21, 2024 at 5:53 PM Brian Geffon <bgeffon@...gle.com> wrote:
>
> On Tue, Oct 15, 2024 at 8:48 AM Greg Kroah-Hartman
> <gregkh@...uxfoundation.org> wrote:
> >
> > On Tue, Oct 15, 2024 at 03:31:57PM +0300, Alexander Usyskin wrote:
> > > Read buffer is allocated according to max message size, reported by
> > > the firmware and may reach 64K in systems with pxp client.
> > > Contiguous 64k allocation may fail under memory pressure.
> > > Read buffer is used as in-driver message storage and not required
> > > to be contiguous.
> > > Use kvmalloc to allow kernel to allocate non-contiguous memory.
> > >
> > > Fixes: 3030dc056459 ("mei: add wrapper for queuing control commands.")
> > > Reported-by: Rohit Agarwal <rohiagar@...omium.org>
> > > Closes: https://lore.kernel.org/all/20240813084542.2921300-1-rohiagar@chromium.org/
> > > Tested-by: Brian Geffon <bgeffon@...gle.com>
> > > Signed-off-by: Alexander Usyskin <alexander.usyskin@...el.com>
> Cc: stable@...r.kernel.org
>
> > > ---
> >
> > Why is this on the -next branch?  You want this merged now, right?
> >
> > Again, I asked "why hasn't this been reviewed by others at Intel", and
> > so I'm just going to delete this series until it has followed the
> > correct Intel-internal review process.
>
> This is a significant crash for us, any chance we can get another
> reviewer from Intel?
>
>
> reviewer from Intel?

(second attempt, forgot to remove html formatting)
I'm no longer with Intel but I'm aware of this fix, so as the former
driver maintainer:
Acked-by: Tomas Winkler <tomasw@...il.com>