Closed Bug 1322784 Opened 6 years ago Closed 5 years ago

Crash in (utime)


(Core :: Security: Process Sandboxing, defect)

Not set



Tracking Status
firefox-esr52 --- unaffected
firefox53 --- wontfix
firefox54 --- wontfix
firefox55 --- fixed


(Reporter: garbas, Assigned: jld)



(Keywords: crash, Whiteboard: sb+)

Crash Data


(1 file)

This bug was filed from the Socorro interface and is 
report bp-49304330-ed12-47f4-9444-027cd2161210.
$ grep -w $[0x84] /usr/include/asm/unistd_64.h
#define __NR_utime 132

I don't understand why GConf/ORBit would need to modify the filesystem to query the value of a configuration directive.

But, if the “stack” (really just the list of things found in stack memory that look like return addresses, because the crash dump processor doesn't have unwind info for the system libraries) is reasonably close to the truth, the underlying cause is something in content trying to use the nsProtocolProxyService.

And if I had to guess what in a content process would be trying to do that, it'd be WebRTC[1], because I've run into that before, but that doesn't actually show up in the crash so I could be wrong about that.

Summary: Crash in → Crash in (utime)
Whiteboard: sb+
On further inspection of the call stack, the thing using the proxy service looks like the NPAPI plugin host:
See Also: → 1294528
(In reply to Jed Davis [:jld] (⏰UTC-6) from comment #2)
> On further inspection of the call stack, the thing using the proxy service
> looks like the NPAPI plugin host:

This was fixed in bug 778201, but we're still seeing occasional crashes in utime via GConf/ORBit from WebRTC (bug 1325242).
I can confirm that this is not an issue for packaging Firefox nightly for NixOS anymore.
I can check (in next week) if this are any problem with WebRTC, since I'm using service quite a lot.
Crash Signature: [@] → [@ ] [@ ]
No longer depends on: 1325242
See Also: → 1325242
Comment on attachment 8872867 [details]
Bug 1322784 - Gently fail utime(), to deal with GConf/ORBit.

Question still remains why it's doing this. Maybe to avoid re-reading config files for changes or something? I guess we can live with this given that it will end up being remoted.
Attachment #8872867 - Flags: review?(gpascutto) → review+
For reference, this is from a function named giop_tmpdir_init in src/orb/GIOP/giop.c in the orbit2 source:

#if defined (HAVE_UTIME_H) && !defined (G_OS_WIN32)
                /* This seems pretty useless, forget it on Win32 */

                { /* Hide some information ( apparently ) */
                        struct utimbuf utb;
                        memset (&utb, 0, sizeof (utb));
                        utime (newname, &utb);

And there's something similar (minus the "pretty useless" comment, which was added several years later) in a function named make_local_tmpdir in linc2/src/linc-protocols.c

The git history goes back to a commit in 2001 that says only “copy from ORBit-stable”.

What it's actually doing (in both cases) is zeroing the mtime and atime on a newly created temporary directory.  I'm not sure what the point is of trying to conceal when the directory was created, but it also doesn't work, because it can't alter the ctime.
Assignee: nobody → jld
Pushed by
Gently fail utime(), to deal with GConf/ORBit. r=gcp
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
Is this something that affects ESR52? I forgot what the status of sandboxing is there.
Flags: needinfo?(jld)
Thanks for checking.  It's not affected: this is specific to content sandboxing, and ESR52 has only media plugin sandboxing.  (Also, 53 and 54 were affected only as Nightly.)
Flags: needinfo?(jld)
You need to log in before you can comment on or make changes to this bug.