linux-kernel - Re: Staging: vt6655/vt6656 security issues

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 27 Sep 2010 12:28:20 -0700
From:	Greg KH <gregkh@...e.de>
To:	Dan Rosenberg <drosenberg@...curity.com>
Cc:	security@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: Staging: vt6655/vt6656 security issues

On Mon, Sep 27, 2010 at 02:30:56PM -0400, Dan Rosenberg wrote:
> Based on a brief glance looking for security issues, I just wanted to
> mention that these drivers are nowhere near ready to be added to the
> main kernel.  I'm not interested in developing these drivers further,
> but there are at least six stack buffer overflows:
> 
> vt6655/wpactl.c: wpa_set_keys(), line 239
> vt6655/wpactl.c: wpa_set_keys(), line 280
> vt6655/wpactl.c: wpa_set_associate(), line 770 (reported by Dan
> Carpenter)
> 
> vt6656/wpactl.c: wpa_set_keys(), line 239
> vt6656/wpactl.c: wpa_set_keys(), line 279
> vt6656/wpactl.c: wpa_set_associate(), line 779
> 
> And four heap corruption issues due to integer overflow in the
> allocation size:
> 
> vt6655/ioctl.c: private_ioctl(), line 329
> vt6655/ioctl.c: private_ioctl(), line 625
> 
> vt6656/ioctl.c: private_ioctl(), line 326
> vt6656/ioctl.c: private_ioctl(), line 615
> 
> They are all caused by unchecked copy_from_user() calls with
> user-provided length fields or kmalloc() calls with arithmetic on
> user-provided sizes.  This kind of sloppiness suggests there are almost
> certainly other major security issues in this code.

I would not doubt that at all.  For the moment, these drivers are being
used to allow users to use their machines, and a "real" driver is soon
replacing them for the long-term.  They also all run on laptops, where
such security issues are not as relevant due to the "physical access"
mode.  Not that this excuses such horrible behavior, but it does lesten
the threat model a lot.

I thank you for your patches and looking into this code, but if you
want, don't really worry about future work in this area, as the drivers
will just be deleted entirely soon (with any luck).

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/