* [PATCH] vt: don't hardcode the mem allocation upper bound
@ 2020-03-28 21:32 Nicolas Pitre
2020-04-17 14:49 ` Sam Ravnborg
0 siblings, 1 reply; 3+ messages in thread
From: Nicolas Pitre @ 2020-03-28 21:32 UTC (permalink / raw)
To: gregkh
Cc: Adam Borowski, Chen Wandun, jslaby, daniel.vetter, sam,
b.zolnierkie, lukas, ghalat, linux-kernel
The code in vc_do_resize() bounds the memory allocation size to avoid
exceeding MAX_ORDER down the kzalloc() call chain and generating a
runtime warning triggerable from user space. However, not only is it
unwise to use a literal value here, but MAX_ORDER may also be
configurable based on CONFIG_FORCE_MAX_ZONEORDER.
Let's use KMALLOC_MAX_SIZE instead.
Note that prior commit bb1107f7c605 ("mm, slab: make sure that
KMALLOC_MAX_SIZE will fit into MAX_ORDER") the KMALLOC_MAX_SIZE value
could not be relied upon.
Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
Cc: <stable@vger.kernel.org> # v4.10+
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 15d2769805..37c5f21490 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -1193,7 +1193,7 @@ static int vc_do_resize(struct tty_struct *tty, struct vc_data *vc,
if (new_cols == vc->vc_cols && new_rows == vc->vc_rows)
return 0;
- if (new_screen_size > (4 << 20))
+ if (new_screen_size > KMALLOC_MAX_SIZE)
return -EINVAL;
newscreen = kzalloc(new_screen_size, GFP_USER);
if (!newscreen)
^ permalink raw reply related [flat|nested] 3+ messages in thread* Re: [PATCH] vt: don't hardcode the mem allocation upper bound
2020-03-28 21:32 [PATCH] vt: don't hardcode the mem allocation upper bound Nicolas Pitre
@ 2020-04-17 14:49 ` Sam Ravnborg
2020-04-23 13:44 ` Greg KH
0 siblings, 1 reply; 3+ messages in thread
From: Sam Ravnborg @ 2020-04-17 14:49 UTC (permalink / raw)
To: Nicolas Pitre, Greg KH
Cc: gregkh, Adam Borowski, Chen Wandun, jslaby, daniel.vetter,
b.zolnierkie, lukas, ghalat, linux-kernel
Hi Greg.
I assume you will take this patch.
Not really drm-misc material.
Sam
On Sat, Mar 28, 2020 at 05:32:42PM -0400, Nicolas Pitre wrote:
> The code in vc_do_resize() bounds the memory allocation size to avoid
> exceeding MAX_ORDER down the kzalloc() call chain and generating a
> runtime warning triggerable from user space. However, not only is it
> unwise to use a literal value here, but MAX_ORDER may also be
> configurable based on CONFIG_FORCE_MAX_ZONEORDER.
> Let's use KMALLOC_MAX_SIZE instead.
>
> Note that prior commit bb1107f7c605 ("mm, slab: make sure that
> KMALLOC_MAX_SIZE will fit into MAX_ORDER") the KMALLOC_MAX_SIZE value
> could not be relied upon.
>
> Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
> Cc: <stable@vger.kernel.org> # v4.10+
>
>
> diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
> index 15d2769805..37c5f21490 100644
> --- a/drivers/tty/vt/vt.c
> +++ b/drivers/tty/vt/vt.c
> @@ -1193,7 +1193,7 @@ static int vc_do_resize(struct tty_struct *tty, struct vc_data *vc,
> if (new_cols == vc->vc_cols && new_rows == vc->vc_rows)
> return 0;
>
> - if (new_screen_size > (4 << 20))
> + if (new_screen_size > KMALLOC_MAX_SIZE)
> return -EINVAL;
> newscreen = kzalloc(new_screen_size, GFP_USER);
> if (!newscreen)
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [PATCH] vt: don't hardcode the mem allocation upper bound
2020-04-17 14:49 ` Sam Ravnborg
@ 2020-04-23 13:44 ` Greg KH
0 siblings, 0 replies; 3+ messages in thread
From: Greg KH @ 2020-04-23 13:44 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Nicolas Pitre, Adam Borowski, Chen Wandun, jslaby, daniel.vetter,
b.zolnierkie, lukas, ghalat, linux-kernel
On Fri, Apr 17, 2020 at 04:49:15PM +0200, Sam Ravnborg wrote:
> Hi Greg.
>
> I assume you will take this patch.
> Not really drm-misc material.
Yes, will do, thanks.
greg k-h
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-04-23 13:45 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-03-28 21:32 [PATCH] vt: don't hardcode the mem allocation upper bound Nicolas Pitre
2020-04-17 14:49 ` Sam Ravnborg
2020-04-23 13:44 ` Greg KH
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.