exynos-mem: Fix major security hole

This fixes the exynos-mem device security hole. The driver allowed any user
to access all of the device's lowmem through the provided mmap functionality.

We create a small little framework collecting the actual CMA memory blocks
that exist on the device; they are the root cause of the existence of this device
driver. We white-list only the CMA memory spaces as parameters to the mmap
function and deny access to any other memory space requests.

We furthermore just allow access to the "s3c-fimc" memory block as this is
seemingly the only space which upon access denial actually breaks functionality.

This patch was modified to be suitable for Exynos 4210 by
Andrew Dodd <atd7@cornell.edu> from Andrei's original Exynos 4412 patch.

Change-Id: Ie5335c1ca81293dc071e919c00524f1e6765e70e
Signed-off-by: Andrew Dodd <atd7@cornell.edu>

Conflicts:
	arch/arm/plat-s5p/reserve_mem.c
Run mptcp_init before TCP initialization

Signed-off-by: Catalin Nicutar <catalin.nicutar@gmail.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>

Conflicts:
	net/mptcp/mptcp_ctrl.c

Signed-off-by: Gregory Detal <gregory.detal@uclouvain.be>
Fix: Take mpcb-mutex when acting upon address-event

We must do this, in order to prevent entering the address-worker while
inside mptcp_close.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Signed-off-by: Gregory Detal <gregory.detal@uclouvain.be>
Fix: Reconstruct skb-mapping, if reinjection failed

mptcp_skb_entail changed seq and end_seq to a subflow-level. If the
reinjection thus fails, mptcp_transmit_skb_failed will put it back on
the reinject-queue.

We have to recover the mapping out of the linear TCP-header.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Signed-off-by: Gregory Detal <gregory.detal@uclouvain.be>
Fix: Remove pointers to socket from subflows upon mptcp_close

Otherwise we will be accessing garbage from the subsockets, as socket will be freed after
the mptcp_close.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Signed-off-by: Gregory Detal <gregory.detal@uclouvain.be>
Fix: triple-lock error when sending reset from mptcp_do_join_short

We may have the following path:
tcp_v4_do_rcv->mptcp_do_join_short->mptcp_v4_do_rcv->tcp_v4_send_reset.

ip_send_reply (from tcp_v4_send_reset) will try to take the lock on the
socket. However, we are already holding two locks. The listener and the
meta. Lockdep will complain here.

So, we propagate the reset-sending up to tcp_rcv_state_process.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Signed-off-by: Gregory Detal <gregory.detal@uclouvain.be>
Fix: Set the correct lock-class for ALL subflows

Subsockets created on the client-side also needs the correct lock class.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Signed-off-by: Gregory Detal <gregory.detal@uclouvain.be>
Fix: mptcp_retransmit_timer

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Signed-off-by: Gregory Detal <gregory.detal@uclouvain.be>
Fix: Only send reset if necessary

Because, the socket may not be correctly initialized (e.g.,
mptcp_init4_subsockets failed). Then, rcv_mss is 0, and
__mptcp_select_window will fail with a 0 divide (called from
tcp_transmit_skb).

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>

Conflicts:
	net/ipv4/tcp.c

Signed-off-by: Gregory Detal <gregory.detal@uclouvain.be>
Fix: Always force-close subflows on tcp_disconnect

Because, afterwards meta_tp->window_clamp will be set to 0. Then, when
we retransmit our MP_FAIL, the socket will select a zero mss in
__mptcp_select_window. This will result in a crash if window-scaling is
turned off.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Signed-off-by: Gregory Detal <gregory.detal@uclouvain.be>
Fix: Hold the subsocket lock in tcp_disconnect

Because, we set mpc to 0, which will mean that tcp_v4_rcv will take the
subsocket's lock. Then we may have a race.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Signed-off-by: Gregory Detal <gregory.detal@uclouvain.be>
Fix: Set icsk_backoff to 0 upon successfull data-delivery

Otherwise, the RTO-timer will get slower and slower.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Signed-off-by: Gregory Detal <gregory.detal@uclouvain.be>
Fix: Race condition while creating subsocket on the server-side

There may happen a race-condition, because tp->mpc is set to 0 in
mptcp_inherit_sk.

What happens:
tp->mpc is set to 0 while creating a new subflow, and added to the
socket-hash-table by tcp_v4_syn_recv_sock. Then, a new packet comes in,
and waits for the lock on the subflow (not on the meta, because tp->mpc
is still 0).

In mptcp_add_sock, tp->mpc will finally be correctly set to 1. But hell,
this is too late. The above packet already came in. We have now a race,
as we are inside a subsocket, without holding the meta-socket lock.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Signed-off-by: Gregory Detal <gregory.detal@uclouvain.be>
Cleanup

Reported-by: Gregory Detal <gregory.detal@uclouvain.be>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Signed-off-by: Gregory Detal <gregory.detal@uclouvain.be>
Fix: Rebuild the mapping on the subflow when fragmenting or trimming

If we loose a mapping due to fragmenting or trimming, the reinjection
cannot work. This will then require the meta-level retransmission timer
to trigger the recovery. This is very slow and may even lead to stalls.

We now reconstruct the mapping when fragmenting or trimming. This allows
us to quickly recover from the loss. In __mptcp_reinject_data, we have
to look for the data from the meta-send-queue in order to reinject it
properly.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Signed-off-by: Gregory Detal <gregory.detal@uclouvain.be>
Fix: NULL-pointer exception in mptcp_del_sock

9c2c649cc57 (Fix: Race condition while creating subsocket on the
server-side) introduced a regression when mptcp_check_req_child fails.
tp->mpc is set, but tp->mptcp not yet. Then, in mptcp_del_sock we will
have a NULL Pointer Exception.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Signed-off-by: Gregory Detal <gregory.detal@uclouvain.be>
Fix: Consider data-fin when checking if the mapping is coherent

If multiple packets cover a single mapping, and a data-fin is part of
this mapping, then the check in mptcp_detect_mapping is wrong.

map_data_len is data_len - 1, if a data-fin is present. We have to
consider this.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Signed-off-by: Gregory Detal <gregory.detal@uclouvain.be>
Fix: Don't check for mptcp-flag data-fin in mptcp_queue_skb

If we receive a data-fin, mptcp_prepare_skb will set tcp_hdr()->fin to
1. If the mapping covers multiple segments however, mptcp_flags will
have the data-fin flag set on each of these segments.

Thus, we should rather check on the more accurate tcp_hdr()->fin flag,
which is only set on the real last segment.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Signed-off-by: Gregory Detal <gregory.detal@uclouvain.be>
Fix: First unlink, then send reset

Otherwise we may corrupt the skb.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Signed-off-by: Gregory Detal <gregory.detal@uclouvain.be>
Fix: Don't use the teardown-flag

We should do a proper close with mptcp_sub_force_close.

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>

Conflicts:
	net/ipv4/tcp_ipv4.c

Signed-off-by: Gregory Detal <gregory.detal@uclouvain.be>