Re: [PATCH v2] platform/chrome: cros_ec_dev - Fix security issue

[Gwendal Grignou]

On Sun, Mar 6, 2016 at 12:11 PM, Olof Johansson  wrote:
> Hi,
>
...
>
> How about you introduce a reasonable max size for a transaction instead
> (256K?), and compare data_size with that? Might want to check with the EC 
> folks
> what they expect larges transactions to be from their side, and go with
> a margin above that.
Make sense, patch coming.
>
>
> Also, in your commit message you should refer to the CVE this fixes.
AFAIK, no CVE for this bug.
>
>
> -Olof

Re: [PATCH v2] platform/chrome: cros_ec_dev - Fix security issue

[Gwendal Grignou]

On Sun, Mar 6, 2016 at 12:11 PM, Olof Johansson  wrote:
> Hi,
>
...
>
> How about you introduce a reasonable max size for a transaction instead
> (256K?), and compare data_size with that? Might want to check with the EC 
> folks
> what they expect larges transactions to be from their side, and go with
> a margin above that.
Make sense, patch coming.
>
>
> Also, in your commit message you should refer to the CVE this fixes.
AFAIK, no CVE for this bug.
>
>
> -Olof

Re: [PATCH v2] platform/chrome: cros_ec_dev - Fix security issue

[Olof Johansson]

Hi,

On Thu, Mar 03, 2016 at 11:00:13AM -0800, Gwendal Grignou wrote:
> Add a check to prevent memory scribble when sending an ioctl with .insize
> set so large that memory allocation argument overflows.
> 
> Signed-off-by: Gwendal Grignou 
> ---
>  drivers/platform/chrome/cros_ec_dev.c | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/chrome/cros_ec_dev.c 
> b/drivers/platform/chrome/cros_ec_dev.c
> index d45cd25..0b2f730 100644
> --- a/drivers/platform/chrome/cros_ec_dev.c
> +++ b/drivers/platform/chrome/cros_ec_dev.c
> @@ -131,13 +131,23 @@ static ssize_t ec_device_read(struct file *filp, char 
> __user *buffer,
>  static long ec_device_ioctl_xcmd(struct cros_ec_dev *ec, void __user *arg)
>  {
>   long ret;
> + size_t data_size;
>   struct cros_ec_command u_cmd;
>   struct cros_ec_command *s_cmd;
>  
>   if (copy_from_user(_cmd, arg, sizeof(u_cmd)))
>   return -EFAULT;
>  
> - s_cmd = kmalloc(sizeof(*s_cmd) + max(u_cmd.outsize, u_cmd.insize),
> + /*
> +  * Prevent malicious attack where .insize is so big that amount
> +  * kmalloc'ed rollover, allowing memcpy to write beyond the allocated
> +  * space.
> +  */
> + data_size = max(u_cmd.outsize, u_cmd.insize);
> + if (data_size + sizeof(*s_cmd) < data_size)
> + return -EINVAL;
> +
> + s_cmd = kmalloc(sizeof(*s_cmd) + data_size,
>   GFP_KERNEL);

This test does work, but it's sort of silly to even try to allow almost 4GB of
allocation here.

How about you introduce a reasonable max size for a transaction instead
(256K?), and compare data_size with that? Might want to check with the EC folks
what they expect larges transactions to be from their side, and go with
a margin above that.


Also, in your commit message you should refer to the CVE this fixes.


-Olof

Re: [PATCH v2] platform/chrome: cros_ec_dev - Fix security issue

[Olof Johansson]

Hi,

On Thu, Mar 03, 2016 at 11:00:13AM -0800, Gwendal Grignou wrote:
> Add a check to prevent memory scribble when sending an ioctl with .insize
> set so large that memory allocation argument overflows.
> 
> Signed-off-by: Gwendal Grignou 
> ---
>  drivers/platform/chrome/cros_ec_dev.c | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/chrome/cros_ec_dev.c 
> b/drivers/platform/chrome/cros_ec_dev.c
> index d45cd25..0b2f730 100644
> --- a/drivers/platform/chrome/cros_ec_dev.c
> +++ b/drivers/platform/chrome/cros_ec_dev.c
> @@ -131,13 +131,23 @@ static ssize_t ec_device_read(struct file *filp, char 
> __user *buffer,
>  static long ec_device_ioctl_xcmd(struct cros_ec_dev *ec, void __user *arg)
>  {
>   long ret;
> + size_t data_size;
>   struct cros_ec_command u_cmd;
>   struct cros_ec_command *s_cmd;
>  
>   if (copy_from_user(_cmd, arg, sizeof(u_cmd)))
>   return -EFAULT;
>  
> - s_cmd = kmalloc(sizeof(*s_cmd) + max(u_cmd.outsize, u_cmd.insize),
> + /*
> +  * Prevent malicious attack where .insize is so big that amount
> +  * kmalloc'ed rollover, allowing memcpy to write beyond the allocated
> +  * space.
> +  */
> + data_size = max(u_cmd.outsize, u_cmd.insize);
> + if (data_size + sizeof(*s_cmd) < data_size)
> + return -EINVAL;
> +
> + s_cmd = kmalloc(sizeof(*s_cmd) + data_size,
>   GFP_KERNEL);

This test does work, but it's sort of silly to even try to allow almost 4GB of
allocation here.

How about you introduce a reasonable max size for a transaction instead
(256K?), and compare data_size with that? Might want to check with the EC folks
what they expect larges transactions to be from their side, and go with
a margin above that.


Also, in your commit message you should refer to the CVE this fixes.


-Olof