Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 234295 - CVE-2007-1353 Bluetooth setsockopt() information leaks
Summary: CVE-2007-1353 Bluetooth setsockopt() information leaks
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: kernel
Version: 2.1
Hardware: i386
OS: Linux
medium
low
Target Milestone: ---
Assignee: Don Howard
QA Contact: Martin Jenner
URL:
Whiteboard: impact=low,source=redhat,reported=200...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-03-28 09:22 UTC by Marcel Holtmann
Modified: 2007-11-30 22:06 UTC (History)
1 user (show)

Fixed In Version: RHSA-2007-0672
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-08-08 18:16:55 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2007:0672 normal SHIPPED_LIVE Important: kernel security update 2007-08-08 18:16:35 UTC

Description Marcel Holtmann 2007-03-28 09:22:16 UTC
Report from Ilja van Sprundel:

The Bluetooth L2CAP setsockopt code has a small information leak. Basically
there is a case where 32 bits of kernel stack memory can get leaked to userland
in l2cap_sock_setsockopt():

static int l2cap_sock_setsockopt(struct socket *sock, int level, int optname,
char __user *optval, int optlen)
{
 struct sock *sk = sock->sk;
 struct l2cap_options opts;
...
 switch (optname) {
 case L2CAP_OPTIONS:
  len = min_t(unsigned int, sizeof(opts), optlen); <-- len can be 0 !!!
  if (copy_from_user((char *) &opts, optval, len)) { <-- no data copied
   err = -EFAULT;
   break;
  }
  l2cap_pi(sk)->imtu  = opts.imtu; <-- uninit 
  l2cap_pi(sk)->omtu  = opts.omtu; <-- uninit
  break;
...
}

So optlen can be 0, so no data is copied into opts, and so whatever is on the
stack at that point will get put in the sk struct. You could use getsockopt() to
retrieve that leaked data. 

Seems the hci_sock_setsockopt() function has a very simular information leak in
the HCI_FILTER case: 

 case HCI_FILTER:
  len = min_t(unsigned int, len, sizeof(uf)); <-- can be 0
  if (copy_from_user(&uf, optval, len)) { <-- no data copied 

So uf remains uninit. A call to getsockopt can retrieved the leaked info.

Comment 4 Red Hat Bugzilla 2007-08-08 18:16:55 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2007-0672.html



Note You need to log in before you can comment on or make changes to this bug.