Ubuntu

usb_find_devices() crashed with SIGSEGV in free()

Reported by Rolando F. Blanco C:. on 2009-09-11
318
This bug affects 65 people
Affects Status Importance Assigned to Milestone
libusb
Won't Fix
Unknown
libusb (Ubuntu)
Medium
Eric Miao
Lucid
Undecided
Martin Pitt
Maverick
Medium
Eric Miao

Bug Description

Binary package hint: devicekit-power

rolando@defiant:~$ lsb_release -rd
Description: Ubuntu karmic (development branch)
Release: 9.10

Hi, I only turn on my computer and then i saw the bug

ProblemType: Crash
Architecture: amd64
Date: Thu Sep 10 04:39:51 2009
DistroRelease: Ubuntu 9.10
ExecutablePath: /usr/lib/devicekit-power/devkit-power-daemon
NonfreeKernelModules: wl nvidia
Package: devicekit-power 010-0ubuntu1
ProcCmdline: /usr/lib/devicekit-power/devkit-power-daemon
ProcEnviron:

ProcVersionSignature: Ubuntu 2.6.31-10.30-generic
SegvAnalysis:
 Segfault happened at: 0x7f8ac7ddf629 <free+25>: mov -0x8(%rdi),%rax
 PC (0x7f8ac7ddf629) ok
 source "-0x8(%rdi)" (0x-0000007) not located in a known VMA region (needed readable region)!
 destination "%rax" ok
SegvReason: reading NULL VMA
Signal: 11
SourcePackage: devicekit-power
StacktraceTop:
 free () from /lib/libc.so.6
 usb_destroy_configuration ()
 usb_free_dev () from /lib/libusb-0.1.so.4
 usb_find_devices () from /lib/libusb-0.1.so.4
 ?? ()
Title: devkit-power-daemon crashed with SIGSEGV in free()
Uname: Linux 2.6.31-10-generic x86_64
UserGroups:

Rolando F. Blanco C:. (rolando) wrote :

StacktraceTop:*__GI___libc_free (mem=0x1) at malloc.c:3687
usb_destroy_configuration (dev=0x66dbe0)
usb_free_dev (dev=0x1) at ../usb.c:293
usb_find_devices () at ../usb.c:121
dkp_device_csr_init (csr=0x66a560)

Changed in devicekit-power (Ubuntu):
importance: Undecided → Medium
tags: removed: need-amd64-retrace
Martin Pitt (pitti) on 2009-10-01
visibility: private → public
Changed in devicekit-power (Ubuntu):
status: New → Confirmed

Crash happens in libusb, reassigning.

affects: devicekit-power (Ubuntu) → libusb (Ubuntu)
summary: - devkit-power-daemon crashed with SIGSEGV in free()
+ usb_find_devices() crashed with SIGSEGV in free()
Changed in libusb:
status: Unknown → New
Märt Suga (mart-suga) wrote :

Could it be duplicate to this?: https://bugs.launchpad.net/ubuntu/+source/pcsc-lite/+bug/551940

Anyway, libusb-0.1 is not supported for a long time now so there is no chance to get a patch from there.

According to libusb developers libusb-compat-0.1 (version 1.0.3) provides backwards compatibility for programs that were linked against libusb-0.1

Is there a chance that this will ever make it to lucid?

Alex Murray (alexmurray) wrote :

Might be worth replacing libusb-0.1 with libusb-compat since anecdotal evidence (https://bugs.launchpad.net/ubuntu/+source/upower/+bug/526895/comments/8) would appear to suggest it fixes this issue.

Märt Suga (mart-suga) wrote :

Could someone instuct how to replave libusb-compat with libusb-0.1
Should I just built the libusb-compat package and name it to libusb-0.1 or should they both be installed?

There seems to be a bunch of duplicates floating around Launchpad. Can someone give me a way to reproduce this bug so we can make sure the other bugs are really duplicates of this one? Thanks in advance!

Alex Murray (alexmurray) wrote :

The ones I manually marked as duplicates all have the same stack-trace which is pretty much a dead give-away. Unfortunately there seems no good way to reproduce it - Fedora also have the exact same issue - https://bugzilla.redhat.com/show_bug.cgi?id=580570 - which is apparently being looked at by the main upower developer (Richard Hughes at redhat) since this seems to trigger the crash in libusb

I attached a debdiff that brings the latest fix from Richard Hughes to the current upower package in Lucid. If you want to test it, you may apply it or wait until the updated package is built and available in my PPA.

Wow, that was quick. The updated packages are available from ppa:philippe-gauthier/ppa

Alex Murray (alexmurray) wrote :

@Philippe - thanks for that, will test later tonight when I get the chance - in the meantime I notice your debdiff says this fixes this bug - unfortunately this bug is against libusb-0.1 which isn't fixed, it just works around upower triggering this bug. Regardless, thanks again for generating the diff - also I think you'll need to look at updating build depends in debian/control so that we build against libusb-1.0-dev not libusb-dev

tags: added: patch

@Alex : The packaging of the patch is quite ugly because I struggled with the autoconf files, and I was happy enough when the source package finally built. If the fix works, I will try to re-package it better, even if it means a little bit more testing... Also, the debian/control file seems to have libusb-1.0-0-dev as a build dependency ; is there something I missed?

Märt Suga (mart-suga) wrote :

So there is absolutely no chance that libusb-0.1 will be fixed or replaced with libusb-compat which also means that there is absolutely no support for years now for libusb-0.1 neither from native developers nor canonical?

By the way this bug is only the top of the iceberg caused by deprecated libusb-0.1

Eric Miao (eric.y.miao) wrote :

This happens intermittently on my Macbook Pro 5.5, so I debugged into this for a while. And found there is an incorrect free due to the memory not being zero-ed during allocation. The attached patch tries to fix this issue (at least it worked on my side). And I've yet built the libusb packages at: http://people.canonical.com/~ycmiao/lp427805/libusb-0.1-4_0.1.12-14~lp427805_amd64.deb. Please test and report back.

Changed in libusb (Ubuntu):
assignee: nobody → Eric Miao (eric.y.miao)
status: Confirmed → In Progress
Märt Suga (mart-suga) wrote :

Can you build a package for i386?
I tried to do it myself, but "debian/rules binary" fails with errors.

Eric Miao (eric.y.miao) wrote :

Try remove config.guess and config.sub before issueing an 'debian/rules binary', ugly but should work.

Alex Murray (alexmurray) wrote :

Thanks Eric, I agree this definitely looks like the potential culprit for this crash. Am just rebuilding libusb now with your patch so I can test it and will report back with results. Thanks again for your effort in debugging this.

Alex Murray (alexmurray) wrote :

Also I've attached a patch which I found on the redhat bugzilla (can't seem to find the original bug report atm) which also addresses a possible logic error in libusb - Eric can you review and perhaps incorporate with the existing patch you've just posted? Cheers?field.comment=Also I've attached a patch which I found on the redhat bugzilla (can't seem to find the original bug report atm) which also addresses a possible logic error in libusb - Eric can you review and perhaps incorporate with the existing patch you've just posted? Cheers

Eric Miao (eric.y.miao) wrote :

@Märt, finally built with my PPA and uploaded both amd64 and i386 version of the package to http://people.canonical.com/~ycmiao/lp427805. Please check and report.

@Alex, yeah the patch looks OK. I'll see if we can get this into lucid-update. Thanks.

Märt Suga (mart-suga) wrote :

I now installed Your new version. Since the bug does not appear every time, I cannot report immediately that it works. I will test for a week and let You know if the bug has reappeared or not.

Eric Miao (eric.y.miao) wrote :

@Märt, yeah that's something nasty. I tried plug and un-plug my power several times but didn't managed to get this reproduced. But once it happens, it seems to last forever. So a possible way to verify is to use the original libusb package first, and til this issue happens, install the updated one, and try start upower on command line to see if it crashes. gnome-power-manager seems to be staying at an incorrect state once upowerd crashes, so you may want to kill and start gnome-power-manager manually to bring it back to a right state.

Erwan Loisant (eloisant) wrote :

@Eric: your package worked for me, on a Macbook Pro 5,5 (amd64). I had the bug, installed it then suspended and it worked (didn't work before). I think it would be good to get this patch to the official repos.

@Eric: same for me on a MacBook Pro 5,5 running lucid. I can now suspend and resume without having libusb segfault in the process. Thanks!

Seems to have fixed the issue on my MB 5,1 running Lucid as well.

-Barry Flanagan

On 9 June 2010 22:42, Olivier Grisel <email address hidden> wrote:
> @Eric: same for me on a MacBook Pro 5,5 running lucid. I can now suspend
> and resume without having libusb segfault in the process. Thanks!
>
> --
> usb_find_devices() crashed with SIGSEGV in free()
> https://bugs.launchpad.net/bugs/427805
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in libusb: New
> Status in “libusb” package in Ubuntu: In Progress
>
> Bug description:
> Binary package hint: devicekit-power
>
> rolando@defiant:~$ lsb_release -rd
> Description:    Ubuntu karmic (development branch)
> Release:        9.10
>
> Hi, I only turn on my computer and then i saw the bug
>
> ProblemType: Crash
> Architecture: amd64
> Date: Thu Sep 10 04:39:51 2009
> DistroRelease: Ubuntu 9.10
> ExecutablePath: /usr/lib/devicekit-power/devkit-power-daemon
> NonfreeKernelModules: wl nvidia
> Package: devicekit-power 010-0ubuntu1
> ProcCmdline: /usr/lib/devicekit-power/devkit-power-daemon
> ProcEnviron:
>
> ProcVersionSignature: Ubuntu 2.6.31-10.30-generic
> SegvAnalysis:
>  Segfault happened at: 0x7f8ac7ddf629 <free+25>:        mov    -0x8(%rdi),%rax
>  PC (0x7f8ac7ddf629) ok
>  source "-0x8(%rdi)" (0x-0000007) not located in a known VMA region (needed readable region)!
>  destination "%rax" ok
> SegvReason: reading NULL VMA
> Signal: 11
> SourcePackage: devicekit-power
> StacktraceTop:
>  free () from /lib/libc.so.6
>  usb_destroy_configuration ()
>  usb_free_dev () from /lib/libusb-0.1.so.4
>  usb_find_devices () from /lib/libusb-0.1.so.4
>  ?? ()
> Title: devkit-power-daemon crashed with SIGSEGV in free()
> Uname: Linux 2.6.31-10-generic x86_64
> UserGroups:
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/libusb/+bug/427805/+subscribe
>

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libusb - 2:0.1.12-15ubuntu1

---------------
libusb (2:0.1.12-15ubuntu1) maverick; urgency=low

  * Add 07_altsetting_alloc.patch: Fix crash due to uninitialized memory.
    Thanks to Eric Miao for debugging this and the patch! (LP: #427805)
 -- Martin Pitt <email address hidden> Tue, 15 Jun 2010 09:19:06 +0200

Changed in libusb (Ubuntu Maverick):
status: In Progress → Fix Released

Accepted libusb into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in libusb (Ubuntu Lucid):
status: New → Fix Committed
tags: added: verification-needed
Alex Murray (alexmurray) wrote :

Thanks Martin, I can confirm this seems to fix the problem for me.

Martin Pitt (pitti) on 2010-07-01
tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libusb - 2:0.1.12-14ubuntu0.1

---------------
libusb (2:0.1.12-14ubuntu0.1) lucid-proposed; urgency=low

  * Add 07_altsetting_alloc.patch: Fix crash due to uninitialized memory.
    Thanks to Eric Miao for debugging this and the patch! (LP: #427805)
 -- Martin Pitt <email address hidden> Tue, 15 Jun 2010 09:26:07 +0200

Changed in libusb (Ubuntu Lucid):
status: Fix Committed → Fix Released

This update seems to be causing some problems for people using HPLIP and HP Laserjet printers. After installing libusb-0.1-4 version 2:0.1.12-14ubuntu0.1 yesterday, I could no longer print on my HP Laserjet 3030 printer and hp-toolbox would report a "Device communication error 5012". Some googling lead me to http://newyork.ubuntuforums.org/showthread.php?t=1518226, so I downgraded, rebooted and now everything seems to be working fine again. Thus, at least two of us seem to be experiencing this problem.

I am running Lucid amd64.

I'm sorry I don't have any additional information, I just thought that it should be reported somewhere and this thread seemed like the right place to do it.

Please let me know if you need anything else.

The above-mentioned problem was also reported to Ubuntu as bug #595650.

Cesare Mastroianni (cece) wrote :

Sorry to bother You ... from bug #595650 ...

I noticed that update manager propose libusb 0.1.12-14ubuntu0.1 as "recommended update" (sorry for my English ... I'm translating from Italian), but I have experienced that this libusb upgrade is faulty, at least for HP printers. Therefore I suppose it could be better to stop announcing it as a "recommended update". As long as people will install it, more and more HP printers stop working (I suppose).

Ciao
CM

Pawel Kot (gnokii) wrote :

The patch applied is actually very wrong. And it breaks for example gnokii.
If you look at the code you find this:

interface->altsetting = realloc(interface->altsetting, sizeof(struct usb_interface_descriptor) * (interface->num_altsetting + 1));

Which means that the structure is reallocated to add new altsetting. If you then zero the whole altsetting you zero all previous altsetting. What about zeroing just allocated space? Please see the attached patch (untested).

dforsi (daniele-forsi) wrote :

With libusb - 2:0.1.12-14ubuntu0.1 and the corresponding -dev package gnokii doesn't find the FBUS endpoint.

I'm attaching the output of lsusb -vvv for a Nokia phone for 2:0.1.12-14 (working) and for 2:0.1.12-14ubuntu0.1 (not working).

dforsi (daniele-forsi) wrote :

This is the output of lsusb -vvv -d 0421: when gnokii is not working.

dforsi (daniele-forsi) wrote :

The patch in comment #33 that only zeroes the last altsetting works for me.

Martin Pitt (pitti) wrote :

Reopening, since this caused regressions and needs a different patch.

Changed in libusb (Ubuntu Maverick):
status: Fix Released → In Progress
Changed in libusb (Ubuntu Lucid):
status: Fix Released → In Progress
Martin Pitt (pitti) wrote :

Indeed the previous patch would overwrite previous altsettings, sorry that I didn't spot this. When I reviewed this original SRU, I just looked at the realloc()/memset() sequence, which seems fine at the first sight. realloc() by no way guarantees you that the reallocated pointer is still the same as the original one, so you would have to copy the previous contents if they are different. But the code does not do that and blindly assumes that the pointer remains constant.

However, Pawel's patch avoids the regression in bug 595650 and does not scribble over the previously written altsettings, so I'll sponsor this into lucid. Thanks a lot!

Changed in libusb (Ubuntu Lucid):
assignee: nobody → Martin Pitt (pitti)
tags: removed: verification-done
Martin Pitt (pitti) wrote :

Updated libusb uploaded to lucid-proposed, awaiting SRU team review.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libusb - 2:0.1.12-15ubuntu2

---------------
libusb (2:0.1.12-15ubuntu2) maverick; urgency=low

  * 07_altsetting_alloc.patch: Update patch to only clear the current
    altsetting record in the loop, not overwrite previously written ones.
    Thanks to Pawel Kot! (LP: #427805, #595650)
 -- Martin Pitt <email address hidden> Mon, 12 Jul 2010 08:20:34 +0200

Changed in libusb (Ubuntu Maverick):
status: In Progress → Fix Released
Pawel Kot (gnokii) wrote :

As for realloc(). It indeed does not guarantee that it will point out to the old chunk of memory. However it does guarantee that it will copy the relevant part of the memory. Reading man realloc:
 The contents will be unchanged to the minimum of the old and new sizes;
So that should be just enough.

Colin Watson (cjwatson) wrote :

Accepted libusb into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in libusb (Ubuntu Lucid):
status: In Progress → Fix Committed
tags: added: verification-needed
Cesare Mastroianni (cece) wrote :

I should be wrong: up to date I'm not able to download the proposed package. Please, see here below ... what should I change to download and test the new patched package?

~$ tail -1 /etc/apt/sources.list
deb http://archive.ubuntu.com/ubuntu/ lucid-proposed restricted main multiverse universe

~$ sudo aptitude install libusb/lucid-proposed
Lettura elenco dei pacchetti... Fatto
Generazione albero delle dipendenze
Lettura informazioni sullo stato... Fatto
Lettura delle informazioni sullo stato esteso
Inizializzazione dello stato dei pacchetti... Fatto
Impossibile trovare il pacchetto «libusb». Ad ogni modo, i seguenti
pacchetti hanno un nome che contiene «libusb»:
  libusbip0 libusb-1.0-0-udeb-dbgsym libusb-1.0-0-dbgsym
  libusb-0.1-4-dbgsym libusbprog0 libusbip0-dbgsym libusb-ruby1.9.1
  libusb-1.0-0-dev libusb-ruby1.8-dbgsym libusb++-0.1-4c2
  libusbmuxd1-dbgsym libusb-ruby1.8 libusb-ruby libusb-dev libusbprog-dev
  libusbmuxd-dev libusb-ruby1.9.1-dbgsym libusb-0.1-4
  libusb++-0.1-4c2-dbgsym libusbmuxd1 libusbprog0-dbgsym libusb++-dev
  libusbip-dev libusb-1.0-0 libusbmuxd1-dbg
Nessun pacchetto verrà installato, aggiornato o rimosso.
0 pacchetti aggiornati, 0 installati, 0 da rimuovere e 54 non aggiornati.
È necessario prelevare 0B di archivi. Dopo l'estrazione, verranno occupati 0B.

Grazie. Ciao.
CM

Cesare Mastroianni (cece) wrote :

Ops! Forget my previous comment #43 ... I installed PROPOSED libusb-0.1-4 and it runs well: IT WORKS FOR ME.

Ciao
Thanks.
CM

Martin Pitt (pitti) on 2010-07-14
tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libusb - 2:0.1.12-14ubuntu0.2

---------------
libusb (2:0.1.12-14ubuntu0.2) lucid-proposed; urgency=low

  * 07_altsetting_alloc.patch: Update patch to only clear the current
    altsetting record in the loop, not overwrite previously written ones.
    Thanks to Pawel Kot! (LP: #427805, #595650)
 -- Martin Pitt <email address hidden> Mon, 12 Jul 2010 08:26:54 +0200

Changed in libusb (Ubuntu Lucid):
status: Fix Committed → Fix Released
Changed in libusb:
status: New → Won't Fix
To post a comment you must log in.