2020-03-28 21:34:03

by Nicolas Pitre

Subject: [PATCH] vt: don't hardcode the mem allocation upper bound

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 <[email protected]>
Cc: <[email protected]> # 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)

2020-04-17 14:51:01

by Sam Ravnborg

Subject: Re: [PATCH] vt: don't hardcode the mem allocation upper bound

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 <[email protected]>
> Cc: <[email protected]> # 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)

2020-04-23 13:47:57

by Greg Kroah-Hartman

Subject: Re: [PATCH] vt: don't hardcode the mem allocation upper bound

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