net sched: fix some kernel memory leaks

We leak at least 32bits of kernel memory to user land in tc dump,
because we dont init all fields (capab ?) of the dumped structure.

Use C99 initializers so that holes and non explicit fields are zeroed.

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Conflicts:

	net/sched/act_nat.c
 net/ipv4: Eliminate kstrdup memory leak

The string clone is only used as a temporary copy of the argument val
within the while loop, and so it should be freed before leaving the
function.  The call to strsep, however, modifies clone, so a pointer to the
front of the string is kept in saved_clone, to make it possible to free it.

The sematic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@r exists@
local idexpression x;
expression E;
identifier l;
statement S;
@@

*x= \(kasprintf\|kstrdup\)(...);
...
if (x == NULL) S
... when != kfree(x)
	when != E = x
if (...) {
  <... when != kfree(x)
* goto l;
  ...>
* return ...;
}
// </smpl>

Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>
 ipv4: force_igmp_version ignored when a IGMPv3 query received

After all these years, it turns out that the
    /proc/sys/net/ipv4/conf/*/force_igmp_version
parameter isn't fully implemented.

*Symptom*:
When set force_igmp_version to a value of 2, the kernel should only perform
multicast IGMPv2 operations (IETF rfc2236).  An host-initiated Join message
will be sent as a IGMPv2 Join message.  But if a IGMPv3 query message is
received, the host responds with a IGMPv3 join message.  Per rfc3376 and
rfc2236, a IGMPv2 host should treat a IGMPv3 query as a IGMPv2 query and
respond with an IGMPv2 Join message.

*Consequences*:
This is an issue when a IGMPv3 capable switch is the querier and will only
issue IGMPv3 queries (which double as IGMPv2 querys) and there's an
intermediate switch that is only IGMPv2 capable.  The intermediate switch
processes the initial v2 Join, but fails to recognize the IGMPv3 Join responses
to the Query, resulting in a dropped connection when the intermediate v2-only
switch times it out.

*Identifying issue in the kernel source*:
The issue is in this section of code (in net/ipv4/igmp.c), which is called when
an IGMP query is received  (from mainline 2.6.36-rc3 gitweb):
 ...
A IGMPv3 query has a length >= 12 and no sources.  This routine will exit after
line 880, setting the general query timer (random timeout between 0 and query
response time).  This calls igmp_gq_timer_expire():
...
.. which only sends a v3 response.  So if a v3 query is received, the kernel
always sends a v3 response.

IGMP queries happen once every 60 sec (per vlan), so the traffic is low.  A
IGMPv3 query *is* a strict superset of a IGMPv2 query, so this patch properly
short circuit's the v3 behaviour.

One issue is that this does not address force_igmp_version=1.  Then again, I've
never seen any IGMPv1 multicast equipment in the wild.  However there is a lot
of v2-only equipment. If it's necessary to support the IGMPv1 case as well:

837         if (len == 8 || IGMP_V2_SEEN(in_dev) || IGMP_V1_SEEN(in_dev)) {

Signed-off-by: David S. Miller <davem@davemloft.net>
ipsec tunnel support
Signed-off-by: scotthartbti <scott@ubuntu.com>
tcp: fix TSO FACK loss marking in tcp_mark_head_lost

When TCP uses FACK algorithm to mark lost packets in
tcp_mark_head_lost(), if the number of packets in the (TSO) skb is
greater than the number of packets that should be marked lost, TCP
incorrectly exits the loop and marks no packets lost in the skb. This
underestimates tp->lost_out and affects the recovery/retransmission.
This patch fargments the skb and marks the correct amount of packets
lost.

Signed-off-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Ilpo JÃ¤rvinen <ilpo.jarvinen@helsinki.fi>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: nobodyAtall <tsogkas@ceid.upatras.gr>
Signed-off-by: garwedgess <garethwilliams21@gmail.com>
Revert "UKSM: default governor."

This reverts commit 0881a3628aa99d675f4f1076a948fa2569dbdd8f.
Revert "UKSM 0.1.2.2"

This reverts commit ef9e0304be58bedb0ea6c4e3a204ac029497ac25.
Revert "Bring binder inline with LMK"

This reverts commit 76fedee2079f2219af6f9b3c2bee1780f5b15d64.
Revert "Update timed_gpio"

This reverts commit 251ac2c5ada467dae719d788a86fdb79ef9ba9b7.
driver/char/random: Entropy tweaks and use only nonblocking
(cherry picked from commit be9b7b4a7e5def0095f0fe2d1199c83001eb2ce1)

Signed-off-by: garwedgess <garethwilliams21@gmail.com>
timed_gpio: backport from CAF @5d92f71e687e4e1a0

Signed-off-by: garwedgess <garethwilliams21@gmail.com>
Backported logger from CAF @nobodyAtall

Signed-off-by: garwedgess <garethwilliams21@gmail.com>
Signed-off-by: scotthartbti <scott@ubuntu.com>

Conflicts:
	drivers/staging/android/logger.c
android:binder changes from 2.6.32.60
 staging/binder: Fix use of uninitialized variable.

Under an extremely rare condition, the variable return_error may
not be set.  This patch initializes the value to a known "bad"
value, and checks before return to ensure return_error has been
set.

Signed-off-by: Nick Kralevich <nnk@google.com>
Signed-off-by: nobodyAtall <tsogkas@ceid.upatras.gr>
binder: backport from CAF 3.4.0
Revert "Backported logger from CAF @nobodyAtall"

This reverts commit 3333fbc31b20852d218732434beeacb8aff3bfa7.
CRC32 library patched up
lib: update crc32 lib from 3.3 kernel git

Signed-off-by: nobodyAtall <tsogkas@ceid.upatras.gr>
Signed-off-by: garwedgess <garethwilliams21@gmail.com>
Signed-off-by: scotthartbti <scott@ubuntu.com>

Conflicts:
	lib/gen_crc32table.c
 fs: use get_random_int() to fix entropy depleting

Entropy is quickly depleted under normal operations like ls(1), cat(1),
etc...  between 2.6.30 to current mainline, for instance:

$ cat /proc/sys/kernel/random/entropy_avail
3428
$ cat /proc/sys/kernel/random/entropy_avail
2911
$cat /proc/sys/kernel/random/entropy_avail
2620

We observed this problem has been occurring since 2.6.30 with
fs/binfmt_elf.c: create_elf_tables()->get_random_bytes(), introduced by
f06295b44c296c8f ("ELF: implement AT_RANDOM for glibc PRNG seeding").

/*
 * Generate 16 random bytes for userspace PRNG seeding.
 */
get_random_bytes(k_rand_bytes, sizeof(k_rand_bytes));

The patch introduces a wrapper around get_random_int() which has lower
overhead than calling get_random_bytes() directly.

With this patch applied:
$ cat /proc/sys/kernel/random/entropy_avail
2731
$ cat /proc/sys/kernel/random/entropy_avail
2802
$ cat /proc/sys/kernel/random/entropy_avail
2878

Analyzed by John Sobecki.

Signed-off-by: Jie Liu <jeff.liu@oracle.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andreas Dilger <aedilger@gmail.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Arnd Bergmann <arnn@arndb.de>
Cc: John Sobecki <john.sobecki@oracle.com>
Cc: James Morris <james.l.morris@oracle.com>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: Ted Ts'o <tytso@mit.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Ulrich Drepper <drepper@redhat.com>

Acked-by: Kees Cook <keescook@chromium.org>
 pids: Fix a race in pid generation that causes pids to be reused imme…

…diately

From: Salman <sqazi@google.com>
Date: Tue, 10 Aug 2010 18:03:16 -0700
Subject: [PATCH] pids: fix a race in pid generation that causes pids to be
 reused immediately

A program that repeatedly forks and waits is susceptible to having the
same pid repeated, especially when it competes with another instance of
the same program.  This is really bad for bash implementation.
Furthermore, many shell scripts assume that pid numbers will not be used
for some length of time.

Race Description:

A                                    B

// pid == offset == n                // pid == offset == n + 1
test_and_set_bit(offset, map->page)
									 test_and_set_bit(offset, map->page);
									 pid_ns->last_pid = pid;
pid_ns->last_pid = pid;
									 // pid == n + 1 is freed (wait())

									 // Next fork()...
									 last = pid_ns->last_pid; // == n
									 pid = last + 1;

Code to reproduce it (Running multiple instances is more effective):

// The distance mod 32768 between two pids, where the first pid is expected
// to be smaller than the second.
int PidDistance(pid_t first, pid_t second) {
  return (second + 32768 - first) % 32768;
}

int main(int argc, char* argv[]) {
  int failed = 0;
  pid_t last_pid = 0;
  int i;
  printf("%d\n", sizeof(pid_t));
  for (i = 0; i < 10000000; ++i) {
	if (i % 32786 == 0)
	  printf("Iter: %d\n", i/32768);
	int child_exit_code = i % 256;
	pid_t pid = fork();
	if (pid == -1) {
	  fprintf(stderr, "fork failed, iteration %d, errno=%d", i, errno);
	  exit(1);
	}
	if (pid == 0) {
	  // Child
	  exit(child_exit_code);
	} else {
	  // Parent
	  if (i > 0) {
		int distance = PidDistance(last_pid, pid);
		if (distance == 0 || distance > 30000) {
		  fprintf(stderr,
				  "Unexpected pid sequence: previous fork: pid=%d, "
				  "current fork: pid=%d for iteration=%d.\n",
				  last_pid, pid, i);
		  failed = 1;
		}
	  }
	  last_pid = pid;
	  int status;
	  int reaped = wait(&status);
	  if (reaped != pid) {
		fprintf(stderr,
				"Wait return value: expected pid=%d, "
				"got %d, iteration %d\n",
				pid, reaped, i);
		failed = 1;
	  } else if (WEXITSTATUS(status) != child_exit_code) {
		fprintf(stderr,
				"Unexpected exit status %x, iteration %d\n",
				WEXITSTATUS(status), i);
		failed = 1;
	  }
	}
  }
  exit(failed);
}

Thanks to Ted Tso for the key ideas of this implementation.

Signed-off-by: Salman Qazi <sqazi@google.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Sukadev Bhattiprolu <sukadev@us.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>