linux-kernel - Re: [PATCH] firewire: nosy: don't read packets bigger than requested

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: <CAG48ez1etiHmD-e9szTEApia9YhUFomCcZM3Yp9wj9xrDWKmzg@mail.gmail.com>
Date:   Mon, 3 Sep 2018 17:55:23 +0200
From:   Jann Horn <jannh@...gle.com>
To:     stefanr@...6.in-berlin.de, linux1394-devel@...ts.sourceforge.net
Cc:     kernel list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] firewire: nosy: don't read packets bigger than requested

On Fri, Jul 6, 2018 at 5:16 PM Jann Horn <jannh@...gle.com> wrote:
> In general, accessing userspace memory beyond the length of the supplied
> buffer in VFS read/write handlers can lead to both kernel memory corruption
> (via kernel_read()/kernel_write(), which can e.g. be triggered via
> sys_splice()) and privilege escalation inside userspace.
>
> Fixes: 286468210d83 ("firewire: new driver: nosy - IEEE 1394 traffic sniffer")
> Signed-off-by: Jann Horn <jannh@...gle.com>
> ---
> No CC stable because this device shouldn't be available to unprivileged
> code by default and should be pretty rare.
>
>  drivers/firewire/nosy.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/firewire/nosy.c b/drivers/firewire/nosy.c
> index a128dd1126ae..732075fc312e 100644
> --- a/drivers/firewire/nosy.c
> +++ b/drivers/firewire/nosy.c
> @@ -161,11 +161,12 @@ packet_buffer_get(struct client *client, char __user *data, size_t user_length)
>         if (atomic_read(&buffer->size) == 0)
>                 return -ENODEV;
>
> -       /* FIXME: Check length <= user_length. */
> -
>         end = buffer->data + buffer->capacity;
>         length = buffer->head->length;
>
> +       if (length > user_length)
> +               return -EINVAL;
> +
>         if (&buffer->head->data[length] < end) {
>                 if (copy_to_user(data, buffer->head->data, length))
>                         return -EFAULT;

Ping. I sent this about two months ago, I haven't received a reply,
and from what I can tell, it hasn't landed in any tree so far...