* Re: [PATCH v2 1/2] obexd: Add obc_session_get_folder function
From: Luiz Augusto von Dentz @ 2013-09-02 10:39 UTC (permalink / raw)
To: Christian Fetzer; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1377866712-5253-1-git-send-email-christian.fetzer@oss.bmw-carit.de>
Hi Christian,
On Fri, Aug 30, 2013 at 3:45 PM, Christian Fetzer
<christian.fetzer@oss.bmw-carit.de> wrote:
> From: Christian Fetzer <christian.fetzer@bmw-carit.de>
>
> This patch extends client session by the tracking of the current folder.
> The current folder can be accessed by obc_session_get_current_folder.
>
> This allows drivers to add a folder property to browsed objects so that
> the application doesn't have to keep track of the folder an object
> belongs to.
> ---
> obexd/client/session.c | 38 ++++++++++++++++++++++++++++++++++++++
> obexd/client/session.h | 2 ++
> 2 files changed, 40 insertions(+)
>
> diff --git a/obexd/client/session.c b/obexd/client/session.c
> index 44e2bf8..632e114 100644
> --- a/obexd/client/session.c
> +++ b/obexd/client/session.c
> @@ -110,6 +110,7 @@ struct obc_session {
> guint watch;
> GQueue *queue;
> guint process_id;
> + char *folder;
> };
>
> static GSList *sessions = NULL;
> @@ -242,6 +243,7 @@ static void session_free(struct obc_session *session)
> g_free(session->owner);
> g_free(session->source);
> g_free(session->destination);
> + g_free(session->folder);
> g_free(session);
> }
>
> @@ -500,6 +502,7 @@ struct obc_session *obc_session_create(const char *source,
> session->destination = g_strdup(destination);
> session->channel = channel;
> session->queue = g_queue_new();
> + session->folder = g_strdup("/");
>
> if (owner)
> obc_session_set_owner(session, owner, owner_disconnected);
> @@ -930,6 +933,11 @@ const char *obc_session_get_target(struct obc_session *session)
> return session->driver->target;
> }
>
> +const char *obc_session_get_folder(struct obc_session *session)
> +{
> + return session->folder;
> +}
> +
> static void setpath_complete(struct obc_session *session,
> struct obc_transfer *transfer,
> GError *err, void *user_data)
> @@ -957,12 +965,39 @@ static void setpath_op_complete(struct obc_session *session,
> data->func(session, NULL, err, data->user_data);
> }
>
> +static void setpath_set_folder(struct obc_session *session, const char *cur)
> +{
> + char *folder = NULL;
> + const char *delim;
> +
> + delim = strrchr(session->folder, '/');
> + if (strlen(cur) == 0 || delim == NULL ||
> + (strcmp(cur, "..") == 0 && delim == session->folder)) {
> + folder = g_strdup("/");
> + } else {
> + if (strcmp(cur, "..") == 0) {
> + folder = g_strndup(session->folder,
> + delim - session->folder);
> + } else {
> + if (g_str_has_suffix(session->folder, "/"))
> + folder = g_strconcat(session->folder,
> + cur, NULL);
> + else
> + folder = g_strconcat(session->folder, "/",
> + cur, NULL);
> + }
> + }
> + g_free(session->folder);
> + session->folder = folder;
> +}
> +
> static void setpath_cb(GObex *obex, GError *err, GObexPacket *rsp,
> gpointer user_data)
> {
> struct pending_request *p = user_data;
> struct setpath_data *data = p->data;
> char *next;
> + char *current;
> guint8 code;
>
> p->req_id = 0;
> @@ -982,6 +1017,9 @@ static void setpath_cb(GObex *obex, GError *err, GObexPacket *rsp,
> return;
> }
>
> + current = data->remaining[data->index - 1];
> + setpath_set_folder(p->session, current);
> +
> /* Ignore empty folder names to avoid resetting the current path */
> while ((next = data->remaining[data->index]) && strlen(next) == 0)
> data->index++;
> diff --git a/obexd/client/session.h b/obexd/client/session.h
> index 319d529..35899bc 100644
> --- a/obexd/client/session.h
> +++ b/obexd/client/session.h
> @@ -58,6 +58,8 @@ const char *obc_session_register(struct obc_session *session,
> const void *obc_session_get_attribute(struct obc_session *session,
> int attribute_id);
>
> +const char *obc_session_get_folder(struct obc_session *session);
> +
> guint obc_session_queue(struct obc_session *session,
> struct obc_transfer *transfer,
> session_callback_t func, void *user_data,
> --
> 1.8.3.4
Both patches applied, thanks.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: Compatible Kernels of a certain BlueZ version
From: wei junping @ 2013-09-02 7:59 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Gustavo Padovan, linux-bluetooth
In-Reply-To: <3EF10060-3C76-4240-832A-901BE2831808@holtmann.org>
Hi Marcel,
Thank you for your reply.
But what do you mean by "refrain from top posting on this mailing
list"? Do you mean I should not have posted this question here? If so,
where should new comers of BlueZ ask for help?
Best Regards,
Tim Wei
2013/9/2 Marcel Holtmann <marcel@holtmann.org>:
> Hi Wei,
>
> please refrain from top posting on this mailing list.
>
>> Thank you for your reply.
>> I am trying to make 4.93 come with Android 3.0.8 work with Kernel
>> 3.9.6, and I found that values of some mgmt macros in user mode are
>> different from those in kernel.
>> For example:
>> In user mode mgmt.h
>> #define MGMT_OP_READ_FEATURES 0x0002
>> struct mgmt_rp_read_features {
>> uint8_t features[8];
>> } __packed;
>>
>> but in kernel mode mgmt.h
>> #define MGMT_OP_READ_COMMANDS 0x0002
>> #define MGMT_READ_COMMANDS_SIZE 0
>> struct mgmt_rp_read_commands {
>> __le16 num_commands;
>> __le16 num_events;
>> __le16 opcodes[0];
>> } __packed;
>>
>> I haven't tried it, but I would think the meaning of the same value in
>> user and kernel should be the same. Is it?
>
> Before Linux 3.4, the mgmt interface was not official and disabled by default. So values and structs changed. Only with Linux 3.4 they became official. And BlueZ 5.x contains the official values as well.
>
> And version before BlueZ 5.0 will use the raw HCI interface and duplicate all the handling in user space.
>
> Regards
>
> Marcel
>
^ permalink raw reply
* Re: [PATCH v2 2/2] obexd: Add property Folder to MAP message
From: Luiz Augusto von Dentz @ 2013-09-02 7:33 UTC (permalink / raw)
To: Christian Fetzer; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1377866712-5253-2-git-send-email-christian.fetzer@oss.bmw-carit.de>
Hi Christian,
On Fri, Aug 30, 2013 at 3:45 PM, Christian Fetzer
<christian.fetzer@oss.bmw-carit.de> wrote:
> From: Christian Fetzer <christian.fetzer@bmw-carit.de>
>
> diff --git a/obexd/client/map.c b/obexd/client/map.c
> index 8864a54..03be77f 100644
> --- a/obexd/client/map.c
> +++ b/obexd/client/map.c
> @@ -123,6 +123,7 @@ struct map_msg {
> char *status;
> uint64_t attachment_size;
> uint8_t flags;
> + char *folder;
> GDBusPendingPropertySet pending;
> };
>
> @@ -379,6 +380,7 @@ static void map_msg_free(void *data)
> g_free(msg->path);
> g_free(msg->subject);
> g_free(msg->handle);
> + g_free(msg->folder);
> g_free(msg->timestamp);
> g_free(msg->sender);
> g_free(msg->sender_address);
> @@ -451,6 +453,16 @@ done:
> msg->pending = 0;
> }
>
> +static gboolean get_folder(const GDBusPropertyTable *property,
> + DBusMessageIter *iter, void *data)
> +{
> + struct map_msg *msg = data;
> +
> + dbus_message_iter_append_basic(iter, DBUS_TYPE_STRING, &msg->folder);
> +
> + return TRUE;
> +}
> +
> static gboolean subject_exists(const GDBusPropertyTable *property, void *data)
> {
> struct map_msg *msg = data;
> @@ -744,6 +756,7 @@ static const GDBusMethodTable map_msg_methods[] = {
> };
>
> static const GDBusPropertyTable map_msg_properties[] = {
> + { "Folder", "s", get_folder },
> { "Subject", "s", get_subject, NULL, subject_exists },
> { "Timestamp", "s", get_timestamp, NULL, timestamp_exists },
> { "Sender", "s", get_sender, NULL, sender_exists },
> @@ -766,7 +779,8 @@ static const GDBusPropertyTable map_msg_properties[] = {
> { }
> };
>
> -static struct map_msg *map_msg_create(struct map_data *data, const char *handle)
> +static struct map_msg *map_msg_create(struct map_data *data, const char *handle,
> + const char *folder)
> {
We can call obc_session_get_folder directly here using data so there
is no need for an extra parameter.
^ permalink raw reply
* Re: Compatible Kernels of a certain BlueZ version
From: Marcel Holtmann @ 2013-09-02 6:06 UTC (permalink / raw)
To: wei junping; +Cc: Gustavo Padovan, linux-bluetooth
In-Reply-To: <CAKCXgJ1rgAk2VXzGsf2Un-mCm4H9MjT76bkh40-26TJ7Nh56Gg@mail.gmail.com>
Hi Wei,
please refrain from top posting on this mailing list.
> Thank you for your reply.
> I am trying to make 4.93 come with Android 3.0.8 work with Kernel
> 3.9.6, and I found that values of some mgmt macros in user mode are
> different from those in kernel.
> For example:
> In user mode mgmt.h
> #define MGMT_OP_READ_FEATURES 0x0002
> struct mgmt_rp_read_features {
> uint8_t features[8];
> } __packed;
>
> but in kernel mode mgmt.h
> #define MGMT_OP_READ_COMMANDS 0x0002
> #define MGMT_READ_COMMANDS_SIZE 0
> struct mgmt_rp_read_commands {
> __le16 num_commands;
> __le16 num_events;
> __le16 opcodes[0];
> } __packed;
>
> I haven't tried it, but I would think the meaning of the same value in
> user and kernel should be the same. Is it?
Before Linux 3.4, the mgmt interface was not official and disabled by default. So values and structs changed. Only with Linux 3.4 they became official. And BlueZ 5.x contains the official values as well.
And version before BlueZ 5.0 will use the raw HCI interface and duplicate all the handling in user space.
Regards
Marcel
^ permalink raw reply
* Re: Compatible Kernels of a certain BlueZ version
From: wei junping @ 2013-09-02 3:11 UTC (permalink / raw)
To: Gustavo Padovan, wei junping, linux-bluetooth
In-Reply-To: <20130901150129.GB7440@joana>
Hi Gustavo,
Thank you for your reply.
I am trying to make 4.93 come with Android 3.0.8 work with Kernel
3.9.6, and I found that values of some mgmt macros in user mode are
different from those in kernel.
For example:
In user mode mgmt.h
#define MGMT_OP_READ_FEATURES 0x0002
struct mgmt_rp_read_features {
uint8_t features[8];
} __packed;
but in kernel mode mgmt.h
#define MGMT_OP_READ_COMMANDS 0x0002
#define MGMT_READ_COMMANDS_SIZE 0
struct mgmt_rp_read_commands {
__le16 num_commands;
__le16 num_events;
__le16 opcodes[0];
} __packed;
I haven't tried it, but I would think the meaning of the same value in
user and kernel should be the same. Is it?
Best Regards,
Tim Wei
2013/9/1 Gustavo Padovan <gustavo@padovan.org>:
> Hi Tim,
>
> 2013-08-31 wei junping <junping.wei@gmail.com>:
>
>> Who can tell me how I know which kernel is compatible with which BlueZ
>> version, for example, BlueZ 5.7? I didn't find any info in the doc
>> folder of the package.
>
> Any BlueZ 5 version works with an 3.4 kernel or newer. The old BlueZ 4 works
> with any kernel out there.
>
> Gustavo
^ permalink raw reply
* Re: [PATCH] Bluetooth: Use devname:vhci module alias for virtual HCI driver
From: Gustavo Padovan @ 2013-09-01 23:21 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1377579758-10105-1-git-send-email-marcel@holtmann.org>
Hi Marcel,
2013-08-26 Marcel Holtmann <marcel@holtmann.org>:
> To allow creating /dev/vhci device node, add the proper module alias for
> this driver.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> drivers/bluetooth/hci_vhci.c | 1 +
> 1 file changed, 1 insertion(+)
Patch has been applied to bluetooth-next. Thanks.
Gustavo
^ permalink raw reply
* Re: 3.11-final plan: unpriviledged user can crash the kernel (using bluetooth rfcomm)
From: Pavel Machek @ 2013-09-01 22:12 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Gustavo Padovan, johan.hedberg, linux-bluetooth, kernel list,
Linus Torvalds, security
In-Reply-To: <B3715CDF-1D85-45C9-9AD1-DBBD0DF24624@holtmann.org>
Hi!
> >>>>>> . Python sources for client/server are at
> >>>>>>
> >>>>>> http://tui.cvs.sourceforge.net/viewvc/tui/tui/liveview/
> >>>>>>
> > So... In 3.11 unpriviledged user can crash the kernel, but the fix is
> > too big, so we release it without the fix?
> >
> > Somehow, I don't think that's good idea.
>
> can you boot a bluetooth-next kernel and see if the planned changes are fixing this or not. I would like to have that confirmed before we start any speculations here.
>
> If the RFCOMM TTY rework that we have in bluetooth-next fixes this issue, then we can have a look at if this can be patched for 3.11 or a stable kernel without having to include the whole patch series. Or if the TTY subsystem changed from 2.6.32 so much that we have to take the whole changes.
>
> However, please also note there is a different between RFCOMM sockets and RFCOMM TTYs. I would be curious if only the TTY part is affected or also the socket part.
>
Well, you are in as good position to repeat it as I am. Sources are in
the CVS referenced above (and they are trivial). The version that
reproduces the problem is marked as such in changelog. I already
modified my system to work (not triggering oopsen)...
Yes, I can probably setup linux-next. It will take some time.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: 3.11-final plan: unpriviledged user can crash the kernel (using bluetooth rfcomm)
From: Marcel Holtmann @ 2013-09-01 20:16 UTC (permalink / raw)
To: Pavel Machek
Cc: Gustavo Padovan, johan.hedberg, linux-bluetooth, kernel list,
Linus Torvalds, security
In-Reply-To: <20130901185038.GA11714@amd.pavel.ucw.cz>
Hi Pavel,
>>>>>> . Python sources for client/server are at
>>>>>>
>>>>>> http://tui.cvs.sourceforge.net/viewvc/tui/tui/liveview/
>>>>>>
>>>>>> . My kernels like to warn about
>>>>> System is debian stable with gnome2.
>>>>
>>>> And no, it is not fixed in 3.11-rc7.
>>>
>>> 2.6.32-5-686 from debian seems to work.
>>
>> Could you try linux-next? We recently pushed a rework of the RFCOMM tty
>> handling, it should fix this. The work was too big to be pushed to 3.11
>
> So... In 3.11 unpriviledged user can crash the kernel, but the fix is
> too big, so we release it without the fix?
>
> Somehow, I don't think that's good idea.
can you boot a bluetooth-next kernel and see if the planned changes are fixing this or not. I would like to have that confirmed before we start any speculations here.
If the RFCOMM TTY rework that we have in bluetooth-next fixes this issue, then we can have a look at if this can be patched for 3.11 or a stable kernel without having to include the whole patch series. Or if the TTY subsystem changed from 2.6.32 so much that we have to take the whole changes.
However, please also note there is a different between RFCOMM sockets and RFCOMM TTYs. I would be curious if only the TTY part is affected or also the socket part.
Regards
Marcel
^ permalink raw reply
* 3.11-final plan: unpriviledged user can crash the kernel (using bluetooth rfcomm)
From: Pavel Machek @ 2013-09-01 18:50 UTC (permalink / raw)
To: Gustavo Padovan, marcel, johan.hedberg, linux-bluetooth,
kernel list, Linus Torvalds
Cc: security
In-Reply-To: <20130901165525.GK7440@joana>
Hi!
> > On Sat 2013-08-31 12:14:51, Pavel Machek wrote:
> > > On Sat 2013-08-31 12:09:33, Pavel Machek wrote:
> > > > Hi!
> > > >
> > > > > . Python sources for client/server are at
> > > > >
> > > > > http://tui.cvs.sourceforge.net/viewvc/tui/tui/liveview/
> > > > >
> > > > > . My kernels like to warn about
> > > > System is debian stable with gnome2.
> > >
> > > And no, it is not fixed in 3.11-rc7.
> >
> > 2.6.32-5-686 from debian seems to work.
>
> Could you try linux-next? We recently pushed a rework of the RFCOMM tty
> handling, it should fix this. The work was too big to be pushed to 3.11
So... In 3.11 unpriviledged user can crash the kernel, but the fix is
too big, so we release it without the fix?
Somehow, I don't think that's good idea.
Do you have an idea what is the impact? Is it crash-the-kernel or
execute-arbitrary-code?
What about:
a) marking CONFIG_RFCOMM as dangerous in the help text. I just
checked, help text makes it sound like a good thing.
(joke) b) renaming CONFIG_RFCOMM to CONFIG_LET_USER_CRASH_KERNEL
or better yet:
c) removing CONFIG_RFCOMM option in affected releases? I know
regressions are bad, but...
Multiuser desktops are not too common these days, but all the
Android cellphones are "multiuser"...
Plus note that bug is so easy to trigger that I hit it in first minute
trying to get non-malicious application to run.
[3.10 seems also affected.]
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH 2/2] Bluetooth: Introduce new HCI socket channel for user operation
From: Gustavo Padovan @ 2013-09-01 17:44 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <28EA1BF5-3484-4ABE-9049-6845F006C778@holtmann.org>
Hi Marcel,
2013-09-01 Marcel Holtmann <marcel@holtmann.org>:
> Hi Gustavo,
>
> >> This patch introcuces a new HCI socket channel that allows user
> >> applications to take control over a specific HCI device. The application
> >> gains exclusive access to this device and forces the kernel to stay away
> >> and not manage it. In case of the management interface it will actually
> >> hide the device.
> >>
> >> Such operation is useful for security testing tools that need to operate
> >> underneath the Bluetooth stack and need full control over a device. The
> >> advantage here is that the kernel still provides the service of hardware
> >> abstraction and HCI level access. The use of Bluetooth drivers for
> >> hardware access also means that sniffing tools like btmon or hcidump
> >> are still working and the whole set of transaction can be traced with
> >> existing tools.
> >>
> >> With the new channel it is possible to send HCI commands, ACL and SCO
> >> data packets and receive HCI events, ACL and SCO packets from the
> >> device. The format follows the well established H:4 protocol.
> >>
> >> The new HCI user channel can only be established when a device has been
> >> through its setup routine and is currently powered down. This is
> >> enforced to not cause any problems with current operations. In addition
> >> only one user channel per HCI device is allowed. It is exclusive access
> >> for one user application. Access to this channel is limited to process
> >> with CAP_NET_RAW capability.
> >>
> >> Using this new facility does not require any external library or special
> >> ioctl or socket filters. Just create the socket and bind it. After that
> >> the file descriptor is ready to speak H:4 protocol.
> >>
> >> struct sockaddr_hci addr;
> >> int fd;
> >>
> >> fd = socket(AF_BLUETOOTH, SOCK_RAW, BTPROTO_HCI);
> >>
> >> memset(&addr, 0, sizeof(addr));
> >> addr.hci_family = AF_BLUETOOTH;
> >> addr.hci_dev = 0;
> >> addr.hci_channel = HCI_CHANNEL_USER;
> >>
> >> bind(fd, (struct sockaddr *) &addr, sizeof(addr));
> >>
> >> The example shows on how to create a user channel for hci0 device. Error
> >> handling has been left out of the example. However with the limitations
> >> mentioned above it is advised to handle errors. Binding of the user
> >> cahnnel socket can fail for various reasons. Specifically if the device
> >> is currently activated by BlueZ or if the access permissions are not
> >> present.
> >>
> >> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> >> ---
> >> include/net/bluetooth/hci.h | 1 +
> >> net/bluetooth/hci_sock.c | 86 ++++++++++++++++++++++++++++++++++++++++++---
> >> 2 files changed, 82 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
> >> index 128157d..30c88b5 100644
> >> --- a/include/net/bluetooth/hci.h
> >> +++ b/include/net/bluetooth/hci.h
> >> @@ -1571,6 +1571,7 @@ struct sockaddr_hci {
> >> #define HCI_DEV_NONE 0xffff
> >>
> >> #define HCI_CHANNEL_RAW 0
> >> +#define HCI_CHANNEL_USER 1
> >> #define HCI_CHANNEL_MONITOR 2
> >> #define HCI_CHANNEL_CONTROL 3
> >
> > Wouldn't this break BlueZ 4.101? It would open the channel 1 thinking it is
> > the CONTROL one but it is not. I think we need to redefine this to 4.
> > I can do this when applying the patch if you are okay with it.
>
> it would not break it since I am explicitly returning EINVAL when you try to establish a user channel with HCI_DEV_NONE.
Fair enough. Both patches have been applied to bluetooth-next. Thanks.
Gustavo
^ permalink raw reply
* Re: [PATCH 2/2] Bluetooth: Introduce new HCI socket channel for user operation
From: Marcel Holtmann @ 2013-09-01 17:27 UTC (permalink / raw)
To: Gustavo Padovan; +Cc: linux-bluetooth
In-Reply-To: <20130901164544.GI7440@joana>
Hi Gustavo,
>> This patch introcuces a new HCI socket channel that allows user
>> applications to take control over a specific HCI device. The application
>> gains exclusive access to this device and forces the kernel to stay away
>> and not manage it. In case of the management interface it will actually
>> hide the device.
>>
>> Such operation is useful for security testing tools that need to operate
>> underneath the Bluetooth stack and need full control over a device. The
>> advantage here is that the kernel still provides the service of hardware
>> abstraction and HCI level access. The use of Bluetooth drivers for
>> hardware access also means that sniffing tools like btmon or hcidump
>> are still working and the whole set of transaction can be traced with
>> existing tools.
>>
>> With the new channel it is possible to send HCI commands, ACL and SCO
>> data packets and receive HCI events, ACL and SCO packets from the
>> device. The format follows the well established H:4 protocol.
>>
>> The new HCI user channel can only be established when a device has been
>> through its setup routine and is currently powered down. This is
>> enforced to not cause any problems with current operations. In addition
>> only one user channel per HCI device is allowed. It is exclusive access
>> for one user application. Access to this channel is limited to process
>> with CAP_NET_RAW capability.
>>
>> Using this new facility does not require any external library or special
>> ioctl or socket filters. Just create the socket and bind it. After that
>> the file descriptor is ready to speak H:4 protocol.
>>
>> struct sockaddr_hci addr;
>> int fd;
>>
>> fd = socket(AF_BLUETOOTH, SOCK_RAW, BTPROTO_HCI);
>>
>> memset(&addr, 0, sizeof(addr));
>> addr.hci_family = AF_BLUETOOTH;
>> addr.hci_dev = 0;
>> addr.hci_channel = HCI_CHANNEL_USER;
>>
>> bind(fd, (struct sockaddr *) &addr, sizeof(addr));
>>
>> The example shows on how to create a user channel for hci0 device. Error
>> handling has been left out of the example. However with the limitations
>> mentioned above it is advised to handle errors. Binding of the user
>> cahnnel socket can fail for various reasons. Specifically if the device
>> is currently activated by BlueZ or if the access permissions are not
>> present.
>>
>> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
>> ---
>> include/net/bluetooth/hci.h | 1 +
>> net/bluetooth/hci_sock.c | 86 ++++++++++++++++++++++++++++++++++++++++++---
>> 2 files changed, 82 insertions(+), 5 deletions(-)
>>
>> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
>> index 128157d..30c88b5 100644
>> --- a/include/net/bluetooth/hci.h
>> +++ b/include/net/bluetooth/hci.h
>> @@ -1571,6 +1571,7 @@ struct sockaddr_hci {
>> #define HCI_DEV_NONE 0xffff
>>
>> #define HCI_CHANNEL_RAW 0
>> +#define HCI_CHANNEL_USER 1
>> #define HCI_CHANNEL_MONITOR 2
>> #define HCI_CHANNEL_CONTROL 3
>
> Wouldn't this break BlueZ 4.101? It would open the channel 1 thinking it is
> the CONTROL one but it is not. I think we need to redefine this to 4.
> I can do this when applying the patch if you are okay with it.
it would not break it since I am explicitly returning EINVAL when you try to establish a user channel with HCI_DEV_NONE.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 2/2] Bluetooth: Fix encryption key size for peripheral role
From: Gustavo Padovan @ 2013-09-01 17:09 UTC (permalink / raw)
To: Andre Guedes; +Cc: linux-bluetooth
In-Reply-To: <1375298729-23513-2-git-send-email-andre.guedes@openbossa.org>
Hi Andre,
2013-07-31 Andre Guedes <andre.guedes@openbossa.org>:
> This patch fixes the connection encryption key size information when
> the host is playing the peripheral role. We should set conn->enc_key_
> size in hci_le_ltk_request_evt, otherwise it is left uninitialized.
>
> Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
> ---
> net/bluetooth/hci_event.c | 2 ++
> 1 file changed, 2 insertions(+)
Patches have been applied to bluetooth.git. Thanks.
Gustavo
^ permalink raw reply
* Re: 3.11-rc7: unpriviledged user crashes kernel using bluetooth
From: Gustavo Padovan @ 2013-09-01 16:55 UTC (permalink / raw)
To: Pavel Machek; +Cc: marcel, johan.hedberg, linux-bluetooth, kernel list
In-Reply-To: <20130831104238.GA7767@amd.pavel.ucw.cz>
Hi Pavel,
2013-08-31 Pavel Machek <pavel@ucw.cz>:
> On Sat 2013-08-31 12:14:51, Pavel Machek wrote:
> > On Sat 2013-08-31 12:09:33, Pavel Machek wrote:
> > > Hi!
> > >
> > > > . Python sources for client/server are at
> > > >
> > > > http://tui.cvs.sourceforge.net/viewvc/tui/tui/liveview/
> > > >
> > > > . My kernels like to warn about
> > > System is debian stable with gnome2.
> >
> > And no, it is not fixed in 3.11-rc7.
>
> 2.6.32-5-686 from debian seems to work.
Could you try linux-next? We recently pushed a rework of the RFCOMM tty
handling, it should fix this. The work was too big to be pushed to 3.11
Gustavo
^ permalink raw reply
* Re: [PATCH] Add a new PID/VID 0cf3/e005 for AR3012.
From: Gustavo Padovan @ 2013-09-01 16:50 UTC (permalink / raw)
To: Peng Chen; +Cc: linux-bluetooth, marcel, kumo, taowang
In-Reply-To: <1377855700-18006-1-git-send-email-pengchen@qca.qualcomm.com>
Hi Peng,
2013-08-30 Peng Chen <pengchen@qti.qualcomm.com>:
> usb device info:
>
> T: Bus=06 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 15 Spd=12 MxCh= 0
> D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
> P: Vendor=0cf3 ProdID=e005 Rev= 0.02
> C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
> I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
> E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
> I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
> I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
> I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
> I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
> I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
>
> Signed-off-by: Peng Chen <pengchen@qca.qualcomm.com>
> ---
> drivers/bluetooth/ath3k.c | 2 ++
> drivers/bluetooth/btusb.c | 1 +
> 2 files changed, 3 insertions(+)
Patch has been applied to bluetooth.git. Thanks.
Gustavo
^ permalink raw reply
* Re: [PATCH 2/2] Bluetooth: Introduce new HCI socket channel for user operation
From: Gustavo Padovan @ 2013-09-01 16:45 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1377578452-7316-2-git-send-email-marcel@holtmann.org>
Hi Marcel,
2013-08-26 Marcel Holtmann <marcel@holtmann.org>:
> This patch introcuces a new HCI socket channel that allows user
> applications to take control over a specific HCI device. The application
> gains exclusive access to this device and forces the kernel to stay away
> and not manage it. In case of the management interface it will actually
> hide the device.
>
> Such operation is useful for security testing tools that need to operate
> underneath the Bluetooth stack and need full control over a device. The
> advantage here is that the kernel still provides the service of hardware
> abstraction and HCI level access. The use of Bluetooth drivers for
> hardware access also means that sniffing tools like btmon or hcidump
> are still working and the whole set of transaction can be traced with
> existing tools.
>
> With the new channel it is possible to send HCI commands, ACL and SCO
> data packets and receive HCI events, ACL and SCO packets from the
> device. The format follows the well established H:4 protocol.
>
> The new HCI user channel can only be established when a device has been
> through its setup routine and is currently powered down. This is
> enforced to not cause any problems with current operations. In addition
> only one user channel per HCI device is allowed. It is exclusive access
> for one user application. Access to this channel is limited to process
> with CAP_NET_RAW capability.
>
> Using this new facility does not require any external library or special
> ioctl or socket filters. Just create the socket and bind it. After that
> the file descriptor is ready to speak H:4 protocol.
>
> struct sockaddr_hci addr;
> int fd;
>
> fd = socket(AF_BLUETOOTH, SOCK_RAW, BTPROTO_HCI);
>
> memset(&addr, 0, sizeof(addr));
> addr.hci_family = AF_BLUETOOTH;
> addr.hci_dev = 0;
> addr.hci_channel = HCI_CHANNEL_USER;
>
> bind(fd, (struct sockaddr *) &addr, sizeof(addr));
>
> The example shows on how to create a user channel for hci0 device. Error
> handling has been left out of the example. However with the limitations
> mentioned above it is advised to handle errors. Binding of the user
> cahnnel socket can fail for various reasons. Specifically if the device
> is currently activated by BlueZ or if the access permissions are not
> present.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> include/net/bluetooth/hci.h | 1 +
> net/bluetooth/hci_sock.c | 86 ++++++++++++++++++++++++++++++++++++++++++---
> 2 files changed, 82 insertions(+), 5 deletions(-)
>
> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
> index 128157d..30c88b5 100644
> --- a/include/net/bluetooth/hci.h
> +++ b/include/net/bluetooth/hci.h
> @@ -1571,6 +1571,7 @@ struct sockaddr_hci {
> #define HCI_DEV_NONE 0xffff
>
> #define HCI_CHANNEL_RAW 0
> +#define HCI_CHANNEL_USER 1
> #define HCI_CHANNEL_MONITOR 2
> #define HCI_CHANNEL_CONTROL 3
Wouldn't this break BlueZ 4.101? It would open the channel 1 thinking it is
the CONTROL one but it is not. I think we need to redefine this to 4.
I can do this when applying the patch if you are okay with it.
Gustavo
^ permalink raw reply
* Re: [PATCH] Bluetooth: Restrict ioctls to HCI raw channel sockets
From: Gustavo Padovan @ 2013-09-01 16:25 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1377535195-12121-1-git-send-email-marcel@holtmann.org>
Hi Marcel,
2013-08-26 Marcel Holtmann <marcel@holtmann.org>:
> The various legacy ioctls used with HCI sockets are limited to raw
> channel only. They are not used on the other channels and also have
> no meaning there. So return an error if tried to use them.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> net/bluetooth/hci_sock.c | 23 +++++++++++++++++------
> 1 file changed, 17 insertions(+), 6 deletions(-)
Patch has been applied to bluetooth-next. Thanks.
Gustavo
^ permalink raw reply
* Re: [PATCH] Bluetooth: Fix error handling for HCI socket options
From: Gustavo Padovan @ 2013-09-01 16:21 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1377534579-5781-1-git-send-email-marcel@holtmann.org>
Hi Marcel,
2013-08-26 Marcel Holtmann <marcel@holtmann.org>:
> The HCI sockets for monitor and control do not support any HCI specific
> socket options and if tried, an error will be returned. However the
> error used is EINVAL and that is not really descriptive. To make it
> clear that these sockets are not handling HCI socket options, return
> EBADFD instead.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> net/bluetooth/hci_sock.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Patch has been applied to bluetooth-next. Thanks.
Gustavo
^ permalink raw reply
* Re: [PATCH] Bluetooth: Report error for HCI reset ioctl when device is down
From: Gustavo Padovan @ 2013-09-01 15:34 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1377575878-2629-1-git-send-email-marcel@holtmann.org>
Hi Marcel,
2013-08-26 Marcel Holtmann <marcel@holtmann.org>:
> Even if this is legacy API, there is no reason to not report a proper
> error when trying to reset a HCI device that is down.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> net/bluetooth/hci_core.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Patch has been applied to bluetooth-next. Thanks.
Gustavo
^ permalink raw reply
* Re: [PATCH] Bluetooth: Fix handling of getsockname() for HCI sockets
From: Gustavo Padovan @ 2013-09-01 15:32 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1377501637-40861-1-git-send-email-marcel@holtmann.org>
Hi Marcel,
2013-08-26 Marcel Holtmann <marcel@holtmann.org>:
> The hci_dev check is not protected and so move it into the socket lock. In
> addition return the HCI channel identifier instead of always 0 channel.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> net/bluetooth/hci_sock.c | 17 +++++++++++------
> 1 file changed, 11 insertions(+), 6 deletions(-)
Patch has been applied to bluetooth-next. Thanks.
Gustavo
^ permalink raw reply
* Re: [PATCH] Bluetooth: Fix handling of getpeername() for HCI sockets
From: Gustavo Padovan @ 2013-09-01 15:31 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1377500790-36821-1-git-send-email-marcel@holtmann.org>
Hi Marcel,
2013-08-26 Marcel Holtmann <marcel@holtmann.org>:
> The HCI sockets do not have a peer associated with it and so make sure
> that getpeername() returns EOPNOTSUPP since this operation is actually
> not supported on HCI sockets.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> net/bluetooth/hci_sock.c | 3 +++
> 1 file changed, 3 insertions(+)
Patch has been applied to bluetooth-next. Thanks.
Gustavo
^ permalink raw reply
* Re: [PATCH] Bluetooth: Refactor raw socket filter into more readable code
From: Gustavo Padovan @ 2013-09-01 15:31 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1377498315-22523-1-git-send-email-marcel@holtmann.org>
Hi Marcel,
2013-08-25 Marcel Holtmann <marcel@holtmann.org>:
> The handling of the raw socket filter is rather obscure code and it gets
> in the way of future extensions. Instead of inline filtering in the raw
> socket packet routine, refactor it into its own function.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> net/bluetooth/hci_sock.c | 64 +++++++++++++++++++++++++++++++-----------------
> 1 file changed, 41 insertions(+), 23 deletions(-)
Patch has been applied to bluetooth-next. Thanks.
Gustavo
^ permalink raw reply
* Re: Compatible Kernels of a certain BlueZ version
From: Gustavo Padovan @ 2013-09-01 15:01 UTC (permalink / raw)
To: wei junping; +Cc: linux-bluetooth
In-Reply-To: <CAKCXgJ03bfgQYPgJt7R9dXPEX9J7ofiEHgbPBDK9-H=ifaLyRw@mail.gmail.com>
Hi Tim,
2013-08-31 wei junping <junping.wei@gmail.com>:
> Who can tell me how I know which kernel is compatible with which BlueZ
> version, for example, BlueZ 5.7? I didn't find any info in the doc
> folder of the package.
Any BlueZ 5 version works with an 3.4 kernel or newer. The old BlueZ 4 works
with any kernel out there.
Gustavo
^ permalink raw reply
* Re: 3.11-rc7: unpriviledged user crashes kernel using bluetooth
From: Pavel Machek @ 2013-08-31 10:42 UTC (permalink / raw)
To: marcel, gustavo, johan.hedberg, linux-bluetooth, kernel list
In-Reply-To: <20130831101451.GC7029@amd.pavel.ucw.cz>
On Sat 2013-08-31 12:14:51, Pavel Machek wrote:
> On Sat 2013-08-31 12:09:33, Pavel Machek wrote:
> > Hi!
> >
> > > . Python sources for client/server are at
> > >
> > > http://tui.cvs.sourceforge.net/viewvc/tui/tui/liveview/
> > >
> > > . My kernels like to warn about
> > System is debian stable with gnome2.
>
> And no, it is not fixed in 3.11-rc7.
2.6.32-5-686 from debian seems to work.
Notice that I probably have modemmanager fighting with my own
server, that is experiencing problem described in
http://ubuntuforums.org/showthread.php?t=2056285 . That still should
not allow me to crash the kernel.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: 3.11-rc2: unpriviledged user crashes kernel using bluetooth
From: Pavel Machek @ 2013-08-31 10:14 UTC (permalink / raw)
To: marcel, gustavo, johan.hedberg, linux-bluetooth, kernel list
In-Reply-To: <20130831100933.GA7029@amd.pavel.ucw.cz>
On Sat 2013-08-31 12:09:33, Pavel Machek wrote:
> Hi!
>
> > . Python sources for client/server are at
> >
> > http://tui.cvs.sourceforge.net/viewvc/tui/tui/liveview/
> >
> > . My kernels like to warn about
> System is debian stable with gnome2.
And no, it is not fixed in 3.11-rc7.
Pavel
pavel@duo:~$ uname -a
Linux duo 3.11.0-rc7+ #309 SMP Sat Aug 31 11:49:01 CEST 2013 i686
GNU/Linux
pavel@duo:~$ sudo cat /proc/kmsg
[sudo] password for pavel:
<4> [<c04f4c6c>] ? tty_buffer_flush+0x1c/0xd0
<4> [<c0463593>] ? debug_check_no_obj_freed+0xe3/0x190
<4> [<c02ee478>] ? final_putname+0x18/0x40
<4> [<c02ee478>] ? final_putname+0x18/0x40
<4> [<c02df45c>] ? do_sys_open+0x19c/0x220
<4> [<c02f0775>] SyS_ioctl+0x45/0x70
<4> [<c0986638>] sysenter_do_call+0x12/0x31
<0>Code: 24 04 fb 0b 00 00 c7 04 24 65 76 b5 c0 e8 57 f3 fa ff 31 c0
eb ad 8d 76 00 8b 44 9e 04 85 c0 89 45 f0 0f 84 b2 fe ff ff 8b 4d f0
<f0> ff 81 04 01 00 00 8b 0d 64 8e d5 c0 8b 9f 3c 04 00 00 85 c9
<4>CR2: 00000000c02e0e52
<4> 00000a67 c0b533ab 0000009f c0238d28 c0238d28 f2ec6e38 f2ec6f6c
f2ec6d10
<4> f549fb5c c0234ecd 00000009 00000000 f549fb64 c0238d28 f549fb70
c09857c5
<4> [<c0234e8a>] warn_slowpath_common+0x7a/0xa0
<4> [<c0238d28>] ? local_bh_enable_ip+0x58/0x80
<4> [<c09857c5>] _raw_write_unlock_bh+0x25/0x30
<4> [<c08c8643>] unix_release_sock+0x73/0x230
<4> [<c02daf4e>] ? kfree_debugcheck+0xe/0x30
<4> [<c08c8814>] unix_release+0x14/0x20
<4> [<c081dd4b>] sock_release+0x1b/0x80
<4> [<c081e0ab>] sock_close+0xb/0x10
<4> [<c02e2688>] __fput+0x88/0x1f0
<4> [<c02e2888>] ____fput+0x8/0x10
<4> [<c024d0d1>] task_work_run+0x81/0xb0
<4> [<c0236e8e>] do_exit+0x22e/0x860
<4> [<c0204c7b>] oops_end+0x8b/0xd0
<4> [<c09863da>] error_code+0x5a/0x60
<4> [<c02e0d4e>] ? do_sync_read+0x6e/0xa0
<4> [<c02e0d4e>] ? do_sync_read+0x6e/0xa0
<4> [<c022d810>] ? __do_page_fault+0x400/0x400
<4> [<c0285bc2>] ? __lock_acquire+0x192/0xcf0
<4> [<c02fbb39>] ? mntput_no_expire+0x19/0xf0
<4> [<c02e0d4e>] ? do_sync_read+0x6e/0xa0
<4> [<c04f4c6c>] ? tty_buffer_flush+0x1c/0xd0
<4> [<c04f4c6c>] tty_buffer_flush+0x1c/0xd0
<4> [<c04ee5cf>] tty_ioctl+0x5bf/0xa80
<4> [<c0285db6>] ? __lock_acquire+0x386/0xcf0
<4> [<c022ea21>] ? kernel_map_pages+0x71/0xf0
<4> [<c04ee010>] ? tty_check_change+0xe0/0xe0
<4> [<c02f0209>] do_vfs_ioctl+0x89/0x5b0
<4> [<c0463593>] ? debug_check_no_obj_freed+0xe3/0x190
<4> [<c02ee478>] ? final_putname+0x18/0x40
<4> [<c02f0775>] SyS_ioctl+0x45/0x70
<4>---[ end trace f66d593cc2b02657 ]---
Message from syslogd@duo at Aug 31 12:13:17 ...
kernel:CPU: 0 PID: 2663 Comm: modem-manager Tainted: G W
3.11.0-rc7+ #309
Message from syslogd@duo at Aug 31 12:13:17 ...
kernel:Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW (2.19 )
03/31/2011
Message from syslogd@duo at Aug 31 12:13:17 ...
kernel:task: f5f16670 ti: f549e000 task.ti: f549e000
Message from syslogd@duo at Aug 31 12:13:17 ...
kernel:Stack:
Message from syslogd@duo at Aug 31 12:13:17 ...
kernel:Call Trace:
Message from syslogd@duo at Aug 31 12:13:17 ...
kernel:EIP: [<c0285bc2>] __lock_acquire+0x192/0xcf0 SS:ESP
0068:f549fdb8
<1>BUG: unable to handle kernel paging request at eb823c24
<1>IP: [<c0462691>] do_raw_spin_lock+0x11/0x140
<4>*pde = 3733f067 *pte = 2b823060
<4>Oops: 0000 [#2] SMP DEBUG_PAGEALLOC
<4>Modules linked in:
<0>CPU: 1 PID: 3804 Comm: modem-manager Tainted: G D W
3.11.0-rc7+ #309
<0>Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW (2.19 )
03/31/2011
<0>task: eae37670 ti: eba0a000 task.ti: eba0a000
<4>EIP: 0060:[<c0462691>] EFLAGS: 00010086 CPU: 1
<4>EIP is at do_raw_spin_lock+0x11/0x140
<4>EAX: eb823c20 EBX: eb823c20 ECX: 00000000 EDX: 00000000
<4>ESI: 00000286 EDI: eb823c20 EBP: eba0be1c ESP: eba0be0c
<4> DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
<4>CR0: 80050033 CR2: eb823c24 CR3: 2acb4000 CR4: 00000710
<0>Stack:
<4> 00000000 eb823c20 00000286 eb823c20 eba0be3c c09856c2 00000000
00000001
<4> 00000000 c04f4c6c eba09f00 eb823c00 eba0be6c c04f4c6c 0000023b
ebf1ac00
<4> 00000f44 00000c4b 00000000 000001c5 0003463b eba09f00 ebf1ac00
00000017
<0>Call Trace:
<4> [<c09856c2>] _raw_spin_lock_irqsave+0x42/0x50
<4> [<c04f4c6c>] ? tty_buffer_flush+0x1c/0xd0
<4> [<c04f4c6c>] tty_buffer_flush+0x1c/0xd0
<4> [<c04ee5cf>] tty_ioctl+0x5bf/0xa80
<4> [<c022ea21>] ? kernel_map_pages+0x71/0xf0
<4> [<c04ee010>] ? tty_check_change+0xe0/0xe0
<4> [<c02f0209>] do_vfs_ioctl+0x89/0x5b0
<4> [<c0463593>] ? debug_check_no_obj_freed+0xe3/0x190
<4> [<c02f90a0>] ? __fd_install+0x20/0x50
<4> [<c02ee478>] ? final_putname+0x18/0x40
<4> [<c02ee478>] ? final_putname+0x18/0x40
<4> [<c02df45c>] ? do_sys_open+0x19c/0x220
<4> [<c02f0775>] SyS_ioctl+0x45/0x70
<4> [<c0986638>] sysenter_do_call+0x12/0x31
<0>Code: 66 ff ff ff eb b9 ba 39 b7 b7 c0 89 d8 e8 58 ff ff ff eb a0
8d b6 00 00 00 00 55 89 e5 83 ec 10 89 5d f4 89 c3 89 75 f8 89 7d fc
<81> 78 04 ad 4e ad de 0f 85 11 01 00 00 64 a1 4c 87 d3 c0 39 43
<0>EIP: [<c0462691>] do_raw_spin_lock+0x11/0x140 SS:ESP 0068:eba0be0c
<4>CR2: 00000000eb823c24
<4>---[ end trace f66d593cc2b02658 ]---
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* 3.10: unpriviledged user crashes kernel using bluetooth
From: Pavel Machek @ 2013-08-31 10:12 UTC (permalink / raw)
To: marcel, gustavo, johan.hedberg, linux-bluetooth, kernel list
In-Reply-To: <20130831100933.GA7029@amd.pavel.ucw.cz>
On Sat 2013-08-31 12:09:33, Pavel Machek wrote:
> Hi!
>
> > . Python sources for client/server are at
> >
> > http://tui.cvs.sourceforge.net/viewvc/tui/tui/liveview/
> >
> > . My kernels like to warn about
> >
> > Aug 31 11:46:37 duo kernel: WARNING: CPU: 1 PID: 1 at
> > net/wireless/reg.c:423 regulatory_init+0x92/0xff()
> > Aug 31 11:46:37 duo kernel: db.txt is empty, you should update it...
> >
> > . 3.10 does not seem to be affected.
>
> When I said 3.10 was not affected, I was wrong. 3.10 survived the
> test, but when I attempted to reboot the box, I got
>
> WARNING: at lib/list_debug.c:59 __list_del_entry+0xac/0xe0()
> list_del_corruption. prev->next should be f44fffd4, but was f44c402c
> ...
> ...Comm: bluetoothd....
> Call trace:
> ...
> __list_del_entry
> cd_forget
> evict
> iput
Aha, I have even better dump in the logs:
<6>cfg80211: Calling CRDA to update world regulatory domain
<6>wlan0: authenticate with 00:11:95:05:30:d7
<6>wlan0: send auth to 00:11:95:05:30:d7 (try 1/3)
<6>iwl3945 0000:03:00.0 wlan0: disabling HT as WMM/QoS is not
supported by the AP
<6>iwl3945 0000:03:00.0 wlan0: disabling VHT as WMM/QoS is not
supported by the AP
<6>wlan0: RX AssocResp from 00:11:95:05:30:d7 (capab=0x401 status=0
aid=2)
<6>wlan0: associated
<4>the code is fine but needs lockdep annotation.
<4>turning off the locking correctness validator.
<4> edd4cc30 f3187db0 c095a48c f3187df0 c027c43e c0b27dcc f5f71670
00000000
<4> 00000000 f3187df4 00000246 edd4cc30 c10253b0 00000000 00000000
c10253b0
<4> [<c095a48c>] dump_stack+0x16/0x18
<4> [<c027c43e>] __lock_acquire+0x71e/0xcf0
<4> [<c027ca74>] lock_acquire+0x64/0x80
<4> [<c04e59ec>] ? tty_buffer_flush+0x1c/0xd0
<4> [<c095d52b>] _raw_spin_lock_irqsave+0x3b/0x50
<4> [<c04e59ec>] ? tty_buffer_flush+0x1c/0xd0
<4> [<c04e59ec>] tty_buffer_flush+0x1c/0xd0
<4> [<c04df38f>] tty_ioctl+0x5bf/0xa80
<4> [<c027c0a6>] ? __lock_acquire+0x386/0xcf0
<4> [<c02e4899>] do_vfs_ioctl+0x89/0x5b0
<4> [<c0455873>] ? debug_check_no_obj_freed+0xe3/0x190
<4> [<c02e2ac8>] ? final_putname+0x18/0x40
<4> [<c095e4b8>] sysenter_do_call+0x12/0x31
<6>wlan0: deauthenticated from 00:11:95:05:30:d7 (Reason: 3)
<6>cfg80211: Calling CRDA to update world regulatory domain
<6>wlan0: authenticate with 00:11:95:05:30:d7
<6>wlan0: send auth to 00:11:95:05:30:d7 (try 1/3)
<6>wlan0: authenticated
<6>iwl3945 0000:03:00.0 wlan0: disabling HT as WMM/QoS is not
supported by the AP
<6>iwl3945 0000:03:00.0 wlan0: disabling VHT as WMM/QoS is not
supported by the AP
<6>wlan0: associate with 00:11:95:05:30:d7 (try 1/3)
<6>wlan0: RX AssocResp from 00:11:95:05:30:d7 (capab=0x401 status=0
aid=2)
<6>wlan0: associated
<6>wlan0: deauthenticated from 00:11:95:05:30:d7 (Reason: 3)
<6>cfg80211: Calling CRDA to update world regulatory domain
<6>wlan0: authenticated
<6>iwl3945 0000:03:00.0 wlan0: disabling HT as WMM/QoS is not
supported by the AP
<6>iwl3945 0000:03:00.0 wlan0: disabling VHT as WMM/QoS is not
supported by the AP
Broadcast message from root@duo (console) (Sat Aug 31 12:05:57 2013):
The system is going down for reboot NOW!
<7>uhci_hcd 0000:00:1d.3: release dev 2 ep81-INT, period 1, phase 0,
23 us
<4>WARNING: at lib/list_debug.c:59 __list_del_entry+0xac/0xe0()
<4>list_del corruption. prev->next should be f44fffd4, but was
f44c402c
<4>Modules linked in:
<4>CPU: 0 PID: 2801 Comm: bluetoothd Tainted: G W 3.10.0+
#293
<4>Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW (2.19 )
03/31/2011
<4> 0000003b f0933e14 c095a48c f0933e3c c022c96f c0b47bcc f0933e68
0000003b
<4> c0454ddc c0454ddc f44c402c f44fffd4 f44c4000 f0933e54 c022ca0e
00000009
<4> f0933e4c c0b47bcc f0933e68 f0933e74 c0454ddc c0b474dd 0000003b
c0b47bcc
<4>Call Trace:
<4> [<c095a48c>] dump_stack+0x16/0x18
<4> [<c022c96f>] warn_slowpath_common+0x5f/0x80
<4> [<c0454ddc>] ? __list_del_entry+0xac/0xe0
<4> [<c0454ddc>] ? __list_del_entry+0xac/0xe0
<4> [<c0454ddc>] __list_del_entry+0xac/0xe0
<4> [<c02d9276>] cd_forget+0x26/0x60
<4> [<c02ebc69>] evict+0x119/0x170
<4> [<c02ebda6>] iput+0xe6/0x170
<4> [<c02e950f>] d_kill+0xaf/0x100
<4> [<c02e9bf6>] dput+0xc6/0x170
<4> [<c02d6d84>] __fput+0x154/0x200
<4> [<c02d6e98>] ____fput+0x8/0x10
<4> [<c0247a61>] task_work_run+0x81/0xb0
<1>BUG: unable to handle kernel paging request at fffffffc
<1>IP: [<c02d3943>] filp_close+0x13/0x80
<4>*pde = 00d14067 *pte = 00000000
<4>Oops: 0000 [#2] SMP DEBUG_PAGEALLOC
<4>Modules linked in:
<0>CPU: 1 PID: 3735 Comm: python Tainted: G D W 3.10.0+ #293
<0>Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW (2.19 )
03/31/2011
<0>task: f29c6670 ti: edf28000 task.ti: edf28000
<4>EIP: 0060:[<c02d3943>] EFLAGS: 00210282 CPU: 1
<4>EIP is at filp_close+0x13/0x80
<4>EAX: ffffffc0 EBX: ffffffc0 ECX: 00000000 EDX: ee297f00
<4>ESI: ee297f00 EDI: f4779be0 EBP: edf29de0 ESP: edf29dd0
<4> DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
<4>CR0: 8005003b CR2: fffffffc CR3: 00d13000 CR4: 00000710
<4>DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
<4>DR6: ffff0ff0 DR7: 00000400
<0>Stack:
<4> 00200246 00000000 0000001f f4779be0 edf29e0c c02ee2a5 00000002
00000001
<4> 00000000 c02ee21a 00000000 ee297f00 f29c6670 ee297f00 f29c6a54
edf29e20
<4> c02ee372 edfdadc0 f29c6670 f29c6a54 edf29e74 c0231e25 c02eff30
00000000
<0>Call Trace:
<4> [<c02ee2a5>] put_files_struct+0xa5/0x130
<4> [<c02ee21a>] ? put_files_struct+0x1a/0x130
<4> [<c02ee372>] exit_files+0x42/0x60
<4> [<c0231e25>] do_exit+0x205/0x850
<4> [<c02eff30>] ? mntput_no_expire+0x30/0xf0
<4> [<c023d454>] ? get_signal_to_deliver+0xa4/0x570
<4> [<c02324a9>] do_group_exit+0x39/0xa0
<4> [<c023d540>] get_signal_to_deliver+0x190/0x570
<4> [<c095db2d>] ? _raw_spin_unlock+0x1d/0x20
<4> [<c0201237>] do_signal+0x37/0x930
<4> [<c07eccc6>] ? sys_recv+0x36/0x40
<4> [<c07ecd7c>] ? SyS_socketcall+0xac/0x290
<4> [<c0201b68>] do_notify_resume+0x38/0x50
<4> [<c095dee2>] work_notifysig+0x24/0x2a
<0>Code: 09 3d fc fd ff ff 74 02 5d c3 b8 fc ff ff ff 5d c3 8d b4 26
00 00 00 00 55 89 e5 83 ec 10 89 5d f4 89 c3 89 75 f8 89 d6 89 7d fc
<8b> 40 3c 85 c0 74 4a 8b 43 14 85 c0 74 3f 8b 48 30 85 c9 74 38
<0>EIP: [<c02d3943>] filp_close+0x13/0x80 SS:ESP 0068:edf29dd0
<4>CR2: 00000000fffffffc
<4>---[ end trace 6a53890e7df0f3dc ]---
<1>Fixing recursive fault but reboot is needed!
<6>wlan0: deauthenticating from 00:11:95:05:30:d7 by local choice
(reason=3)
<6>cfg80211: Calling CRDA to update world regulatory domain
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox