kernel_samsung_smdk4412/net/ipv4, branch replicant-6.0

net: ping: Fix stack buffer overflow in ping_common_sendmsg()

2016-12-12T13:14:53+00:00

In ping_common_sendmsg(), when len < icmph_len, memcpy_fromiovec()
will access invalid memory because msg->msg_iov only has 1 element
and memcpy_fromiovec() attempts to increment it. KASAN report:

BUG: KASAN: stack-out-of-bounds in memcpy_fromiovec+0x60/0x114 at addr ffffffc071077da0
Read of size 8 by task trinity-c2/9623
page:ffffffbe034b9a08 count:0 mapcount:0 mapping:          (null) index:0x0
flags: 0x0()
page dumped because: kasan: bad access detected
CPU: 0 PID: 9623 Comm: trinity-c2 Tainted: G    BU         3.18.0-dirty #15
Hardware name: Google Tegra210 Smaug Rev 1,3+ (DT)
Call trace:
[] dump_backtrace+0x0/0x1ac arch/arm64/kernel/traps.c:90
[] show_stack+0x10/0x1c arch/arm64/kernel/traps.c:171
[<     inline     >] __dump_stack lib/dump_stack.c:15
[] dump_stack+0x7c/0xd0 lib/dump_stack.c:50
[<     inline     >] print_address_description mm/kasan/report.c:147
[<     inline     >] kasan_report_error mm/kasan/report.c:236
[] kasan_report+0x380/0x4b8 mm/kasan/report.c:259
[<     inline     >] check_memory_region mm/kasan/kasan.c:264
[] __asan_load8+0x20/0x70 mm/kasan/kasan.c:507
[] memcpy_fromiovec+0x5c/0x114 lib/iovec.c:15
[<     inline     >] memcpy_from_msg include/linux/skbuff.h:2667
[] ping_common_sendmsg+0x50/0x108 net/ipv4/ping.c:674
[] ping_v4_sendmsg+0xd8/0x698 net/ipv4/ping.c:714
[] inet_sendmsg+0xe0/0x12c net/ipv4/af_inet.c:749
[<     inline     >] __sock_sendmsg_nosec net/socket.c:624
[<     inline     >] __sock_sendmsg net/socket.c:632
[] sock_sendmsg+0x124/0x164 net/socket.c:643
[<     inline     >] SYSC_sendto net/socket.c:1797
[] SyS_sendto+0x178/0x1d8 net/socket.c:1761
Memory state around the buggy address:
 ffffffc071077c80: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 f1 f1
 ffffffc071077d00: f1 f1 04 f4 f4 f4 f2 f2 f2 f2 04 f4 f4 f4 f2 f2
>ffffffc071077d80: f2 f2 00 00 f4 f4 f2 f2 f2 f2 00 00 00 00 00 00
                               ^
 ffffffc071077e00: 00 f4 f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 00
 ffffffc071077e80: 00 00 00 00 00 00 f3 f3 f3 f3 00 00 00 00 00 00

RM-290

Bug: 31349935
Change-Id: Ib7385fc26dfe7e07e9bab42a10ff65a37cbaab54
Signed-off-by: Siqi Lin

netfilter: x_tables: make sure e->next_offset covers remaining blob size

2016-07-22T13:05:20+00:00

Otherwise this function may read data beyond the ruleset blob.

Change-Id: I22f514057d3e0403d1af61f4d9555403ab9f72ea
Signed-off-by: Florian Westphal 
Signed-off-by: Pablo Neira Ayuso

ipv4: Don't do expensive useless work during inetdev destroy.

2016-05-06T12:57:05+00:00

commit fbd40ea0180a2d328c5adc61414dc8bab9335ce2 upstream.

When an inetdev is destroyed, every address assigned to the interface
is removed.  And in this scenerio we do two pointless things which can
be very expensive if the number of assigned interfaces is large:

1) Address promotion.  We are deleting all addresses, so there is no
   point in doing this.

2) A full nf conntrack table purge for every address.  We only need to
   do this once, as is already caught by the existing
   masq_dev_notifier so masq_inet_event() can skip this.

Change-Id: I4b2a3ed665543728451c21465fb90ec89f739135
Reported-by: Solar Designer 
Signed-off-by: David S. Miller 
Tested-by: Cyrill Gorcunov 
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings

netfilter: x_tables: fix unconditional helper

2016-05-06T12:56:33+00:00

Ben Hawkes says:

 In the mark_source_chains function (net/ipv4/netfilter/ip_tables.c) it
 is possible for a user-supplied ipt_entry structure to have a large
 next_offset field. This field is not bounds checked prior to writing a
 counter value at the supplied offset.

Problem is that mark_source_chains should not have been called --
the rule doesn't have a next entry, so its supposed to return
an absolute verdict of either ACCEPT or DROP.

However, the function conditional() doesn't work as the name implies.
It only checks that the rule is using wildcard address matching.

However, an unconditional rule must also not be using any matches
(no -m args).

The underflow validator only checked the addresses, therefore
passing the 'unconditional absolute verdict' test, while
mark_source_chains also tested for presence of matches, and thus
proceeeded to the next (not-existent) rule.

Unify this so that all the callers have same idea of 'unconditional rule'.

Change-Id: I82cf878cc77aa1b65ce492c8f12bd5c93a4d084e
Reported-by: Ben Hawkes 
Signed-off-by: Florian Westphal 
Signed-off-by: Pablo Neira Ayuso

Revert "udp: remove redundant variable"

2016-03-15T08:44:54+00:00

This reverts commit 81d54ec8479a2c695760da81f05b5a9fb2dbe40a.

If we take the "try_again" goto, due to a checksum error,
the 'len' has already been truncated.  So we won't compute
the same values as the original code did.

Change-Id: I0503e45682377965571c4544385811765ef2e2bb
Reported-by: paul bilke 
Signed-off-by: David S. Miller 
(cherry picked from commit 7c3b1de9c0ba32bd33ac15c62e8b8a0548641c6b)

net: add length argument to skb_copy_and_csum_datagram_iovec

2016-03-15T07:27:51+00:00

Without this length argument, we can read past the end of the iovec in
memcpy_toiovec because we have no way of knowing the total length of the
iovec's buffers.

This is needed for stable kernels where 89c22d8c3b27 ("net: Fix skb
csum races when peeking") has been backported but that don't have the
ioviter conversion, which is almost all the stable trees <= 3.18.

This also fixes a kernel crash for NFS servers when the client uses
 -onfsvers=3,proto=udp to mount the export.

Change-Id: I1865e3d7a1faee42a5008a9ad58c4d3323ea4bab
Signed-off-by: Sabrina Dubroca 
Reviewed-by: Hannes Frederic Sowa 
(cherry picked from commit c91234366e4cfd4f70c73e7d79ede92a6e462a88)

net: ipv4: current group_info should be put after using.

2016-03-15T06:57:24+00:00

Plug a group_info refcount leak in ping_init.
group_info is only needed during initialization and
the code failed to release the reference on exit.
While here move grabbing the reference to a place
where it is actually needed.

Change-Id: I423dff6dda7ab91cdfdacb332330745739e1936d
Signed-off-by: Chuansheng Liu 
Signed-off-by: Zhang Dongxing 
Signed-off-by: xiaoming wang 
Signed-off-by: David S. Miller

tcp_cubic: do not set epoch_start in the future

2016-02-23T00:36:23+00:00

Tracking idle time in bictcp_cwnd_event() is imprecise, as epoch_start
is normally set at ACK processing time, not at send time.

Doing a proper fix would need to add an additional state variable,
and does not seem worth the trouble, given CUBIC bug has been there
forever before Jana noticed it.

Let's simply not set epoch_start in the future, otherwise
bictcp_update() could overflow and CUBIC would again
grow cwnd too fast.

This was detected thanks to a packetdrill test Neal wrote that was flaky
before applying this fix.

Change-Id: I600d3a8ac0ed1d70f3ff5cc6b7341ac13178f4f3
Fixes: 30927520dbae ("tcp_cubic: better follow cubic curve after idle period")
Signed-off-by: Eric Dumazet 
Signed-off-by: Neal Cardwell 
Signed-off-by: Yuchung Cheng 
Cc: Jana Iyengar 
Signed-off-by: David S. Miller 
Signed-off-by: Andrea Arcangeli

tcp_cubic: better follow cubic curve after idle period

2016-02-23T00:36:05+00:00

Jana Iyengar found an interesting issue on CUBIC :

The epoch is only updated/reset initially and when experiencing losses.
The delta "t" of now - epoch_start can be arbitrary large after app idle
as well as the bic_target. Consequentially the slope (inverse of
ca->cnt) would be really large, and eventually ca->cnt would be
lower-bounded in the end to 2 to have delayed-ACK slow-start behavior.

This particularly shows up when slow_start_after_idle is disabled
as a dangerous cwnd inflation (1.5 x RTT) after few seconds of idle
time.

Jana initial fix was to reset epoch_start if app limited,
but Neal pointed out it would ask the CUBIC algorithm to recalculate the
curve so that we again start growing steeply upward from where cwnd is
now (as CUBIC does just after a loss). Ideally we'd want the cwnd growth
curve to be the same shape, just shifted later in time by the amount of
the idle period.

Change-Id: Ia99e2743517729b1c0589fbb8db9965ec806043b
Reported-by: Jana Iyengar 
Signed-off-by: Eric Dumazet 
Signed-off-by: Yuchung Cheng 
Signed-off-by: Neal Cardwell 
Cc: Stephen Hemminger 
Cc: Sangtae Ha 
Cc: Lawrence Brakmo 
Signed-off-by: David S. Miller 
Signed-off-by: Andrea Arcangeli

ipv4: try to cache dst_entries which would cause a redirect

2016-02-23T00:35:36+00:00

Not caching dst_entries which cause redirects could be exploited by hosts
on the same subnet, causing a severe DoS attack. This effect aggravated
since commit f88649721268999 ("ipv4: fix dst race in sk_dst_get()").

Lookups causing redirects will be allocated with DST_NOCACHE set which
will force dst_release to free them via RCU.  Unfortunately waiting for
RCU grace period just takes too long, we can end up with >1M dst_entries
waiting to be released and the system will run OOM. rcuos threads cannot
catch up under high softirq load.

Attaching the flag to emit a redirect later on to the specific skb allows
us to cache those dst_entries thus reducing the pressure on allocation
and deallocation.

This issue was discovered by Marcelo Leitner.

Cc: Julian Anastasov 
Signed-off-by: Marcelo Leitner 
Signed-off-by: Florian Westphal 
Signed-off-by: Hannes Frederic Sowa 
Signed-off-by: Julian Anastasov 
Signed-off-by: David S. Miller 

Conflicts:
	include/net/ip.h
	net/ipv4/route.c

Change-Id: I53e4b500a4db2f5fece937a42a3bd810b2640c44