dbus inherits parent filedescriptors

Bug #230877 reported by Markus Rechberger
22
Affects Status Importance Assigned to Milestone
D-Bus
Fix Released
Medium
dbus (Ubuntu)
Fix Released
Undecided
Martin Pitt
Hardy
Fix Released
Undecided
Martin Pitt
Intrepid
Fix Released
Undecided
Martin Pitt

Bug Description

Binary package hint: dbus

When running mplayer the dbus library forks out the dbus-launcher which inherits the filedescriptors of mplayer.
If one of those filedescriptors accesses a video4linux or DVB device the filehandle will be kept open. In case of multistandard devices which support analog TV or digital TV (or other modes) this will lock the device in the corresponding mode until someone kills the dbus daemon.

Attached you can find a patch against the ubuntu dbus package

English:
http://ubuntuforums.org/showthread.php?t=652941
German:
http://www.ubuntu-forum.de/artikel/29814/dbus-blockiert-datei-nach-mplayer-aufruf.html

Related branches

CVE References

Revision history for this message
In , Colin Walters (walters) wrote :

Created an attachment (id=16558)
don't inherit fds

Revision history for this message
In , Markus Rechberger (mrechberger-empiatech) wrote :

Created an attachment (id=16559)
removed the if check

Revision history for this message
In , Colin Walters (walters) wrote :

I was about to follow up on that =)

Looks like a reasonable patch to me.

Revision history for this message
In , Hp-pobox (hp-pobox) wrote :

(From update of attachment 16559)
This should look more like in glib/gspawn.c ; should use fdwalk() if available, and probably sysconf() or getrlimit() would be more modern than getdtablesize().

Can't just cut-and-paste glib code though, due to license. Maybe the author of that code would be willing to relicense, though it is not complex to reimplement.

Revision history for this message
Markus Rechberger (mrechberger-empiatech) wrote :

Binary package hint: dbus

When running mplayer the dbus library forks out the dbus-launcher which inherits the filedescriptors of mplayer.
If one of those filedescriptors accesses a video4linux or DVB device the filehandle will be kept open. In case of multistandard devices which support analog TV or digital TV (or other modes) this will lock the device in the corresponding mode until someone kills the dbus daemon.

Attached you can find a patch against the ubuntu dbus package

English:
http://ubuntuforums.org/showthread.php?t=652941
German:
http://www.ubuntu-forum.de/artikel/29814/dbus-blockiert-datei-nach-mplayer-aufruf.html

Revision history for this message
Markus Rechberger (mrechberger-empiatech) wrote :
Revision history for this message
MarkusRechberger (mrechberger) wrote :
Revision history for this message
Markus Rechberger (mrechberger-empiatech) wrote :
Revision history for this message
In , MarkusRechberger (mrechberger) wrote :

Created an attachment (id=16665)
using posix sysconf(_SC_OPEN_MAX) instead getdtablesize

Revision history for this message
In , Colin Walters (walters) wrote :

I had a quick look at how Python's subprocess module does it; it basically uses sysconf to get the max fds, and then calls a new function "os.closerange", which is just a basic loop doing close() over the fd range.

fdwalk() seems like a Solaris-specific function? I would say let a patch for that be written/tested by someone from the OpenSolaris community if they want it.

Stylistically this patch doesn't match the rest of the code - need a space between name and function call and the for loop.

After that's fixed r=me.

Changed in dbus:
status: Unknown → In Progress
Revision history for this message
In , Colin Walters (walters) wrote :

commit e2bc7232069b14b7299cb8b2eab436f60a232007
Author: Colin Walters <email address hidden>
Date: Wed May 28 16:01:22 2008 -0400

    Bug 15947: Close file descriptors before execing helper (Markus Rechberger)

     * dbus/dbus-sysdeps-unix.c (_dbus_get_autolaunch_address):
     Close file descriptors before exec.

Changed in dbus:
status: In Progress → Fix Released
Revision history for this message
Peter Meiser (meiser79) wrote :

Hi,

a fix was commited upstream: http://gitweb.freedesktop.org/?p=dbus/dbus.git;a=commitdiff;h=e2bc7232069b14b7299cb8b2eab436f60a232007
I'm attaching it here. Would be great if it was included in a hardy-proposed package.

Revision history for this message
In , Colin Walters (walters) wrote :

*** Bug 10777 has been marked as a duplicate of this bug. ***

Revision history for this message
Martin Pitt (pitti) wrote :

Will fix in Intrepid soon, and then backport to Hardy once we get a reproducible test case.

Changed in dbus:
assignee: nobody → pitti
status: New → Fix Committed
Revision history for this message
Erik Frisk (erik-frisk) wrote :

I'd like to bump this, problem still exists here.

Revision history for this message
Markus Rechberger (mrechberger-empiatech) wrote : RE: [Bug 230877] Re: dbus inherits parent filedescriptors

--- Erik Frisk <email address hidden> schrieb:

> I'd like to bump this, problem still exists here.
>

I think the problem still exists if an application
opens a memory mapping to a v4l device and dbus forks
off afterwards.
This is moreover a design bug in that case and
applications should be pinned somewhere in order to
rebase the dbus or alsa (->only has the memory mapping
problem) implementation in the corresponding
applications, forking off before setting up mappings
will work fine.

Markus

> --
> dbus inherits parent filedescriptors
> https://bugs.launchpad.net/bugs/230877
> You received this bug notification because you are a
> direct subscriber
> of the bug.
>
> Status in D-Bus: Fix Released
> Status in “dbus” source package in Ubuntu: Fix
> Committed
>
> Bug description:
> Binary package hint: dbus
>
> When running mplayer the dbus library forks out the
> dbus-launcher which inherits the filedescriptors of
> mplayer.
> If one of those filedescriptors accesses a
> video4linux or DVB device the filehandle will be
> kept open. In case of multistandard devices which
> support analog TV or digital TV (or other modes)
> this will lock the device in the corresponding mode
> until someone kills the dbus daemon.
>
> Attached you can find a patch against the ubuntu
> dbus package
>
> English:
> http://ubuntuforums.org/showthread.php?t=652941
> German:
>
http://www.ubuntu-forum.de/artikel/29814/dbus-blockiert-datei-nach-mplayer-aufruf.html
>

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package dbus - 1.2.4-0ubuntu1

---------------
dbus (1.2.4-0ubuntu1) intrepid; urgency=low

  * New upstream bug fix release: (LP: #279425)
    - Fix crash on dbus_signature_validate("a{(ii)i}", NULL), which would
      unexpectedly abort the calling program. [CVE-2008-3834]
    - Close file descriptors before exec()ing helpers, to avoid locking
      hardware like video cards by eternally open file fds. (LP: #230877)
    - A small number of compilation and portability fixes.

 -- Martin Pitt <email address hidden> Tue, 07 Oct 2008 15:26:32 +0200

Changed in dbus:
status: Fix Committed → Fix Released
Revision history for this message
Martin Pitt (pitti) wrote :

Hardy update uploaded, waiting for Steve to accept.

Changed in dbus:
assignee: nobody → pitti
status: New → In Progress
Revision history for this message
Steve Langasek (vorlon) wrote :

Accepted into -proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in dbus:
status: In Progress → Fix Committed
Revision history for this message
Kees Cook (kees) wrote :

The proposed update needs to be re-spun to include the ubuntu3.1 security update.

Revision history for this message
Martin Pitt (pitti) wrote :

Re-applied on top of security update. Please test and give feedback here. Thanks!

dbus (1.1.20-1ubuntu3.2) hardy-proposed; urgency=low

  * Add debian/patches/04_helper_fd_leak.patch: Close file descriptors before
    exec()ing helpers, to avoid locking hardware like video cards by eternally
    open file fds. (LP: #230877)

 -- Martin Pitt <email address hidden> Tue, 14 Oct 2008 20:18:24 +0200

Revision history for this message
NoOp (glgxg) wrote :

This update doesn't play well with my Initio SCSI card. Immediately following these updated today:

Upgraded the following (Proposed) packages:
dbus (1.1.20-1ubuntu3) to 1.1.20-1ubuntu3.2
dbus-x11 (1.1.20-1ubuntu3) to 1.1.20-1ubuntu3.2
libdbus-1-3 (1.1.20-1ubuntu3) to 1.1.20-1ubuntu3.2
libdbus-1-dev (1.1.20-1ubuntu3) to 1.1.20-1ubuntu3.2
libexif12 (0.6.16-2.1) to 0.6.16-2.1ubuntu0.1
libexiv2-2 (0.16-3ubuntu1) to 0.16-3ubuntu1.1

I got the following in my kern.log:

Reset SCSI Bus ...
BUG: soft lockup - CPU#0 stuck for 11s! [modprobe:1583]

Pid: 1583, comm: modprobe Not tainted (2.6.24-21-generic #1)
EIP: 0060:[<f896b0a2>] EFLAGS: 00000206 CPU: 0
EIP is at initio_reset_scsi+0x52/0x70 [initio]
EAX: fffee992 EBX: f7f64e78 ECX: 0000a400 EDX: fffee9a6
ESI: 0000000a EDI: f7f64f7c EBP: f7f64e78 ESP: f7fd7dc8
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
CR0: 8005003b CR2: b7e16040 CR3: 37fdd000 CR4: 000006d0
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400
[<f896dc1b>] initio_probe_one+0x67b/0x6d0 [initio]
etc.

Let me know if you'd like a copy of my kern.log and kern.log0.

Revision history for this message
Steve Langasek (vorlon) wrote :

NoOp,

Please open a separate bug report for that problem. dbus didn't break your kernel, it's coincidence that this happened after this update.

Revision history for this message
Martin Pitt (pitti) wrote :

NoOp [2008-10-15 16:32 -0000]:
> This update doesn't play well with my Initio SCSI card. Immediately
> following these updated today:
>
> Upgraded the following (Proposed) packages:
> dbus (1.1.20-1ubuntu3) to 1.1.20-1ubuntu3.2
> [...]
> Reset SCSI Bus ...
> BUG: soft lockup - CPU#0 stuck for 11s! [modprobe:1583]
>
> Pid: 1583, comm: modprobe Not tainted (2.6.24-21-generic #1)
> EIP: 0060:[<f896b0a2>] EFLAGS: 00000206 CPU: 0
> EIP is at initio_reset_scsi+0x52/0x70 [initio]
> EAX: fffee992 EBX: f7f64e78 ECX: 0000a400 EDX: fffee9a6
> ESI: 0000000a EDI: f7f64f7c EBP: f7f64e78 ESP: f7fd7dc8
> DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> CR0: 8005003b CR2: b7e16040 CR3: 37fdd000 CR4: 000006d0
> DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> DR6: ffff0ff0 DR7: 00000400
> [<f896dc1b>] initio_probe_one+0x67b/0x6d0 [initio]

Are you sure you didn't get similar things before? It doesn't look
related to any change in dbus or exiv.

Does it actually cause harm? It isn't a kernel crash or anything
like that, I thought it would only be a warning.

If you get that again, can you please look for the affected "Pid:" and
use "ps aux|grep 1234" (with the pid number instead of 1234, of
course) to see which process got locked up?

Revision history for this message
NoOp (glgxg) wrote :

Will do.

Revision history for this message
NoOp (glgxg) wrote :

@Martin: No, I've looked at the kern.log(s) and this only occurred following the update and the reboot. The SCSI is functioning (it does connect to the scanner properly - the scanner is now no longer scanning properly, but thats most likely another issue).

ps aux|grep 1583:

$ ps aux|grep 1583
gg2xp 6769 0.0 0.0 4064 760 pts/0 R+ 10:15 0:00 grep 1583

@Steve: I'll open another bug after doing some testing first: reboot to ensure it's repeatable, back down to 3.1, etc., etc. Thanks.

Revision history for this message
NoOp (glgxg) wrote :

It was the libexiv2-2 (0.16-3ubuntu1) to 0.16-3ubuntu1.1 update that
also installed libkexiv2-3 as part of the update that created the
problem. I'll file a bug on that - sorry for the spam.

Revision history for this message
Martin Pitt (pitti) wrote :

Any other testers for this?

Revision history for this message
Martin Pitt (pitti) wrote :

Anyone who uses this d-bus version on hardy who can confirm that everything works normally, such as mounting USB sticks, network-manager, etc.?

Revision history for this message
Albert Damen (albrt) wrote :

I have installed dbus, dbus-x11 and libdbus-1-3 from hardy-proposed (1.1.20-1ubuntu3.2) since yesterday and found no regressions.
- plugging in a USB memory stick opens a nautilus window showing the contents of the memory stick
- disabling networking in the network-manager applet sets firefox, evolution and liferea in off-line mode. Enabling networking again puts the applications back in on-line mode.
- pulling the mains plug (laptop) pops up the corresponding message from gnome-power-manager ("Battery Discharging....").

Revision history for this message
Martin Pitt (pitti) wrote :

copied to hardy-updates.

Changed in dbus:
status: Fix Committed → Fix Released
Changed in dbus:
importance: Unknown → Medium
Changed in dbus:
importance: Medium → Unknown
Changed in dbus:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.