linux-kernel - RE: [char-misc-next] 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CY5PR11MB63665F42CE8EDCD3D48D2A27ED7B2@CY5PR11MB6366.namprd11.prod.outlook.com>
Date: Sun, 13 Oct 2024 14:22:27 +0000
From: "Usyskin, Alexander" <alexander.usyskin@...el.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC: "Weil, Oren jer" <oren.jer.weil@...el.com>, Tomas Winkler
	<tomasw@...il.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [char-misc-next] mei: use kvmalloc for read buffer

> -----Original Message-----
> From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> Sent: Sunday, October 13, 2024 3:14 PM
> To: Usyskin, Alexander <alexander.usyskin@...el.com>
> Cc: Weil, Oren jer <oren.jer.weil@...el.com>; Tomas Winkler
> <tomasw@...il.com>; linux-kernel@...r.kernel.org
> Subject: Re: [char-misc-next] mei: use kvmalloc for read buffer
> 
> On Sun, Oct 13, 2024 at 02:53:14PM +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 in this case.
> >
> > Signed-off-by: Alexander Usyskin <alexander.usyskin@...el.com>
> > ---
> >  drivers/misc/mei/client.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> What about this thread:
> 	https://lore.kernel.org/all/20240813084542.2921300-1-
> rohiagar@...omium.org/
> 
> No attribution for the reporter?  Does it solve their problem?
> 
This patch is a result from non-public bug report on ChromeOS.
Their symptoms are not the same as in the thread above.
But, as you rightly point out, this patch should also fix above problem.
I'll add attribution in v2.

> And why such a short line-length in the changelog?
I've tried to split logically with not passing 75 characters.
Will try to re-shuffle in v2.

> 
> Also, where is this memory pressure coming from, what is the root cause
> and what commit does this fix?  Stable backports needed?  Anything else?
> 
The ChromeOS is extremely short on memory by design and can trigger
this situation very easily.
I do not think that this patch fixes any commit - the problematic code exists
from the earliest versions of this driver.
As this problem reproduced only on ChromeOS I believe that no need
in wide backport, the ChromeOS can cherry-pick the patch.
From your experience, is this the right strategy? 

> And who inside Intel reviewed this before sending this out?  Why are
> they not credited here properly?
> 
My bad, lost the tested-by tag in patch preparations.
Will add in v2.

> thanks,
> 
> greg k-h

- - 
Thanks,
Sasha