Closed Bug 969715 Opened 6 years ago Closed 3 years ago

WebRTC creates a PF_NETLINK socket in the content process


(Core :: WebRTC: Signaling, defect, P2)

Gonk (Firefox OS)



Tracking Status
firefox55 --- fixed
Blocking Flags:


(Reporter: jld, Assigned: jesup)




(1 file)

0 + 0xcf00
 1!getifaddrs [ifaddrs_android.cpp : 119 + 0x7]
 2!sctp_init_vrf_list [sctp_bsd_addr.c : 460 + 0x9]
 3!sctp_pcb_init [sctp_pcb.c : 6745 + 0x5]
 4!sctp_init [sctp_usrreq.c : 162 + 0x3]
 5!usrsctp_init [user_socket.c : 81 + 0x3]
 6!mozilla::DataChannelConnection::Init(unsigned short, unsigned short, bool) [DataChannel.cpp : 343 + 0xb]
 7!sipcc::PeerConnectionImpl::EnsureDataConnection(unsigned short) [PeerConnectionImpl.cpp : 952 + 0xf]
 8!sipcc::PeerConnectionImpl::CreateDataChannel(nsAString_internal const&, nsAString_internal const&, unsigned short, bool, unsigned short, unsigned short, bool, unsigned short, nsDOMDataChannel**) [PeerConnectionImpl.cpp : 1030 + 0x3]
 9!sipcc::PeerConnectionImpl::CreateDataChannel(nsAString_internal const&, nsAString_internal const&, unsigned short, bool, unsigned short, unsigned short, bool, unsigned short, mozilla::ErrorResult&) [PeerConnectionImpl.cpp : 1004 + 0x13]
10!mozilla::dom::PeerConnectionImplBinding::createDataChannel [PeerConnectionImplBinding.cpp : 917 + 0x2d]

This should be remoted to the parent process at some point in this stack.
Bug 916427 and changes to the config we use should eliminate any external socket creation.
Assignee: nobody → rjesup
Should this be marked as depending on bug 916427?
Flags: needinfo?(rjesup)
A relevant fact: our content processes already can't create AF_INET or AF_INET6 sockets — they aren't in the AID_NET group and the kernel has CONFIG_ANDROID_PARANOID_NETWORK=y.  So if usrsctp is trying to do any of that in the content process, then it's already broken on b2g.
If I modify the syscall filter to reject all socket()s with EACCES, then the mochitests in gecko/dom/media/tests all pass and the test at appears to work.  So that seems to also be possible as a workaround (and indicates that whatever is going on in sctp_pcb_init isn't actually necessary).
Blocks: 2.0-seccomp
No longer blocks: 932104
This is no longer a seccomp blocker, as of bug 974230; clearing needinfo.
Flags: needinfo?(rjesup)
Since we landed Bug 916427 I should look at this again - the dependency was missing
Depends on: 916427
Priority: -- → P3
Target Milestone: --- → mozilla33
Target Milestone: mozilla33 → mozilla35
Blocks: b2g-seccomp
No longer blocks: 2.0-seccomp
Depends on: sdparta
No longer depends on: sdparta
backlog: --- → webRTC+
Rank: 35
See Also: → 1322506
Michael - FYI.  I'll look at this soon
Rank: 35 → 25
Flags: needinfo?(rjesup)
Priority: P3 → P2
The call is needed if you want to support SCTP/IPv4 or SCTP/IPv6 or SCTP/UDP/IPv4 or SCTP/UDP/IPv6. However, for SCTP/DTLS/UDP/IPv4 or SCTP/DTLS/UDP/IPv6 as used by WebRTC this is not needed.
You can disable the support of SCTP/IPv4 or SCTP/IPv6 or SCTP/UDP/IPv4 or SCTP/UDP/IPv6 by NOT defining INET and INET6 when compiling the usrsctp stack and in all files which include usrsctp.h.

You can remove INET from
and INET6 from

There should be no change for WebRTC.
Flags: needinfo?(rjesup)
Comment on attachment 8817593 [details]
Bug 969715: remove INET and INET6 from sctp build env.
Attachment #8817593 - Flags: review?(rjesup) → review+
Pushed by
remove INET and INET6 from sctp build env. r=jesup
Closed: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.