dbus inherits parent filedescriptors
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| D-Bus |
Fix Released
|
Medium
|
||
| dbus (Ubuntu) |
Undecided
|
Martin Pitt | ||
| Hardy |
Undecided
|
Martin Pitt | ||
| Intrepid |
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://
German:
http://
Related branches
CVE References
Created an attachment (id=16559)
removed the if check
|
#3 |
I was about to follow up on that =)
Looks like a reasonable patch to me.
|
#4 |
(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.
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://
German:
http://
MarkusRechberger (mrechberger) wrote : | #7 |
https:/
this bug got reported earlier here
Created an attachment (id=16665)
using posix sysconf(
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 |
commit e2bc7232069b14b
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-
Close file descriptors before exec.
Changed in dbus: | |
status: | In Progress → Fix Released |
Whoopie (whoopie79) wrote : | #12 |
Hi,
a fix was commited upstream: http://
I'm attaching it here. Would be great if it was included in a hardy-proposed package.
*** Bug 10777 has been marked as a duplicate of this bug. ***
Martin Pitt (pitti) wrote : | #14 |
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 |
Erik Frisk (erik-frisk) wrote : | #15 |
I'd like to bump this, problem still exists here.
Markus Rechberger (mrechberger-empiatech) wrote : RE: [Bug 230877] Re: dbus inherits parent filedescriptors | #16 |
--- 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:/
> 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://
> German:
>
http://
>
Launchpad Janitor (janitor) wrote : | #17 |
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_
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 |
Martin Pitt (pitti) wrote : | #18 |
Hardy update uploaded, waiting for Steve to accept.
Changed in dbus: | |
assignee: | nobody → pitti |
status: | New → In Progress |
Steve Langasek (vorlon) wrote : | #19 |
Accepted into -proposed, please test and give feedback here. Please see https:/
Changed in dbus: | |
status: | In Progress → Fix Committed |
Kees Cook (kees) wrote : | #20 |
The proposed update needs to be re-spun to include the ubuntu3.1 security update.
Martin Pitt (pitti) wrote : | #21 |
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/
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
NoOp (glgxg) wrote : | #22 |
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_
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_
etc.
Let me know if you'd like a copy of my kern.log and kern.log0.
Steve Langasek (vorlon) wrote : | #23 |
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.
Martin Pitt (pitti) wrote : | #24 |
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_
> 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_
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?
NoOp (glgxg) wrote : | #25 |
Will do.
NoOp (glgxg) wrote : | #26 |
@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.
NoOp (glgxg) wrote : | #27 |
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.
Martin Pitt (pitti) wrote : | #28 |
Any other testers for this?
Martin Pitt (pitti) wrote : | #29 |
Anyone who uses this d-bus version on hardy who can confirm that everything works normally, such as mounting USB sticks, network-manager, etc.?
Albert Damen (albrt) wrote : | #30 |
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....").
Martin Pitt (pitti) wrote : | #31 |
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 |
Created an attachment (id=16558)
don't inherit fds