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: <2024101343-proposal-gatherer-8c43@gregkh>
Date: Sun, 13 Oct 2024 14:14:10 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Alexander Usyskin <alexander.usyskin@...el.com>
Cc: Oren Weil <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@chromium.org/

No attribution for the reporter?  Does it solve their problem?

And why such a short line-length in the changelog?

Also, where is this memory pressure coming from, what is the root cause
and what commit does this fix?  Stable backports needed?  Anything else?

And who inside Intel reviewed this before sending this out?  Why are
they not credited here properly?

thanks,

greg k-h