commit b375a75787daf96b7c6bfae272edb2720a9fedfc
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed May 1 09:41:42 2013 -0700

    Linux 3.4.43

commit 1d0dd1db15bc5dedc25bcdebf3dd382436f11f8a
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Apr 16 12:55:41 2013 +0000

    net: drop dst before queueing fragments
    
    [ Upstream commit 97599dc792b45b1669c3cdb9a4b365aad0232f65 ]
    
    Commit 4a94445c9a5c (net: Use ip_route_input_noref() in input path)
    added a bug in IP defragmentation handling, as non refcounted
    dst could escape an RCU protected section.
    
    Commit 64f3b9e203bd068 (net: ip_expire() must revalidate route) fixed
    the case of timeouts, but not the general problem.
    
    Tom Parkin noticed crashes in UDP stack and provided a patch,
    but further analysis permitted us to pinpoint the root cause.
    
    Before queueing a packet into a frag list, we must drop its dst,
    as this dst has limited lifetime (RCU protected)
    
    When/if a packet is finally reassembled, we use the dst of the very
    last skb, still protected by RCU and valid, as the dst of the
    reassembled packet.
    
    Use same logic in IPv6, as there is no need to hold dst references.
    
    Reported-by: Tom Parkin <tparkin@katalix.com>
    Tested-by: Tom Parkin <tparkin@katalix.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ca4bf7c6970aee586c4b6b642e011e3847ac5f93
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Apr 19 15:32:32 2013 +0000

    net: fix incorrect credentials passing
    
    [ Upstream commit 83f1b4ba917db5dc5a061a44b3403ddb6e783494 ]
    
    Commit 257b5358b32f ("scm: Capture the full credentials of the scm
    sender") changed the credentials passing code to pass in the effective
    uid/gid instead of the real uid/gid.
    
    Obviously this doesn't matter most of the time (since normally they are
    the same), but it results in differences for suid binaries when the wrong
    uid/gid ends up being used.
    
    This just undoes that (presumably unintentional) part of the commit.
    
    Reported-by: Andy Lutomirski <luto@amacapital.net>
    Cc: Eric W. Biederman <ebiederm@xmission.com>
    Cc: Serge E. Hallyn <serge@hallyn.com>
    Cc: David S. Miller <davem@davemloft.net>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4087320fd8d0164c4b53fe5f9c26c0d3eaba7d2d
Author: Ben Greear <greearb@candelatech.com>
Date:   Fri Apr 19 10:45:52 2013 +0000

    net: rate-limit warn-bad-offload splats.
    
    [ Upstream commit c846ad9b880ece01bb4d8d07ba917734edf0324f ]
    
    If one does do something unfortunate and allow a
    bad offload bug into the kernel, this the
    skb_warn_bad_offload can effectively live-lock the
    system, filling the logs with the same error over
    and over.
    
    Add rate limitation to this so that box remains otherwise
    functional in this case.
    
    Signed-off-by: Ben Greear <greearb@candelatech.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7575f50ffc847587909648242efdfd0951eb27b9
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Apr 19 07:19:48 2013 +0000

    tcp: call tcp_replace_ts_recent() from tcp_ack()
    
    [ Upstream commit 12fb3dd9dc3c64ba7d64cec977cca9b5fb7b1d4e ]
    
    commit bd090dfc634d (tcp: tcp_replace_ts_recent() should not be called
    from tcp_validate_incoming()) introduced a TS ecr bug in slow path
    processing.
    
    1 A > B P. 1:10001(10000) ack 1 <nop,nop,TS val 1001 ecr 200>
    2 B < A . 1:1(0) ack 1 win 257 <sack 9001:10001,TS val 300 ecr 1001>
    3 A > B . 1:1001(1000) ack 1 win 227 <nop,nop,TS val 1002 ecr 200>
    4 A > B . 1001:2001(1000) ack 1 win 227 <nop,nop,TS val 1002 ecr 200>
    
    (ecr 200 should be ecr 300 in packets 3 & 4)
    
    Problem is tcp_ack() can trigger send of new packets (retransmits),
    reflecting the prior TSval, instead of the TSval contained in the
    currently processed incoming packet.
    
    Fix this by calling tcp_replace_ts_recent() from tcp_ack() after the
    checks, but before the actions.
    
    Reported-by: Yuchung Cheng <ycheng@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a009d58e52a816355a2423729c9aeded56fc40d1
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Thu Feb 7 00:55:37 2013 +0000

    net: sctp: sctp_auth_key_put: use kzfree instead of kfree
    
    [ Upstream commit 586c31f3bf04c290dc0a0de7fc91d20aa9a5ee53 ]
    
    For sensitive data like keying material, it is common practice to zero
    out keys before returning the memory back to the allocator. Thus, use
    kzfree instead of kfree.
    
    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Acked-by: Vlad Yasevich <vyasevich@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d768ca1b9fae5c2ee68ad39e6b1b5e9fc23ca9bf
Author: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Date:   Sat Apr 13 15:49:03 2013 +0000

    esp4: fix error return code in esp_output()
    
    [ Upstream commit 06848c10f720cbc20e3b784c0df24930b7304b93 ]
    
    Fix to return a negative error code from the error handling
    case instead of 0, as returned elsewhere in this function.
    
    Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
    Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ca6ad5d7758a96ef3cea419efe39b3281a5017b5
Author: Thomas Graf <tgraf@suug.ch>
Date:   Thu Apr 11 10:57:18 2013 +0000

    tcp: Reallocate headroom if it would overflow csum_start
    
    [ Upstream commit 50bceae9bd3569d56744882f3012734d48a1d413 ]
    
    If a TCP retransmission gets partially ACKed and collapsed multiple
    times it is possible for the headroom to grow beyond 64K which will
    overflow the 16bit skb->csum_start which is based on the start of
    the headroom. It has been observed rarely in the wild with IPoIB due
    to the 64K MTU.
    
    Verify if the acking and collapsing resulted in a headroom exceeding
    what csum_start can cover and reallocate the headroom if so.
    
    A big thank you to Jim Foraker <foraker1@llnl.gov> and the team at
    LLNL for helping out with the investigation and testing.
    
    Reported-by: Jim Foraker <foraker1@llnl.gov>
    Signed-off-by: Thomas Graf <tgraf@suug.ch>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d0d7ee05a623ba00e4ffc4a07e67c6649cac5cae
Author: Dmitry Popov <dp@highloadlab.com>
Date:   Thu Apr 11 08:55:07 2013 +0000

    tcp: incoming connections might use wrong route under synflood
    
    [ Upstream commit d66954a066158781ccf9c13c91d0316970fe57b6 ]
    
    There is a bug in cookie_v4_check (net/ipv4/syncookies.c):
    	flowi4_init_output(&fl4, 0, sk->sk_mark, RT_CONN_FLAGS(sk),
    			   RT_SCOPE_UNIVERSE, IPPROTO_TCP,
    			   inet_sk_flowi_flags(sk),
    			   (opt && opt->srr) ? opt->faddr : ireq->rmt_addr,
    			   ireq->loc_addr, th->source, th->dest);
    
    Here we do not respect sk->sk_bound_dev_if, therefore wrong dst_entry may be
    taken. This dst_entry is used by new socket (get_cookie_sock ->
    tcp_v4_syn_recv_sock), so its packets may take the wrong path.
    
    Signed-off-by: Dmitry Popov <dp@highloadlab.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f29e2461ef6daf7440d00b3ea5978f69f6c057cb
Author: Michael Riesch <michael.riesch@omicron.at>
Date:   Mon Apr 8 05:45:26 2013 +0000

    rtnetlink: Call nlmsg_parse() with correct header length
    
    [ Upstream commit 88c5b5ce5cb57af6ca2a7cf4d5715fa320448ff9 ]
    
    Signed-off-by: Michael Riesch <michael.riesch@omicron.at>
    Cc: Jiri Benc <jbenc@redhat.com>
    Cc: "Theodore Ts'o" <tytso@mit.edu>
    Acked-by: Mark Rustad <mark.d.rustad@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1ab6b2a5a0970c887166b732fd3ad347979f2cec
Author: Patrick McHardy <kaber@trash.net>
Date:   Fri Apr 5 20:42:05 2013 +0200

    netfilter: don't reset nf_trace in nf_reset()
    
    [ Upstream commit 124dff01afbdbff251f0385beca84ba1b9adda68 ]
    
    Commit 130549fe ("netfilter: reset nf_trace in nf_reset") added code
    to reset nf_trace in nf_reset(). This is wrong and unnecessary.
    
    nf_reset() is used in the following cases:
    
    - when passing packets up the the socket layer, at which point we want to
      release all netfilter references that might keep modules pinned while
      the packet is queued. nf_trace doesn't matter anymore at this point.
    
    - when encapsulating or decapsulating IPsec packets. We want to continue
      tracing these packets after IPsec processing.
    
    - when passing packets through virtual network devices. Only devices on
      that encapsulate in IPv4/v6 matter since otherwise nf_trace is not
      used anymore. Its not entirely clear whether those packets should
      be traced after that, however we've always done that.
    
    - when passing packets through virtual network devices that make the
      packet cross network namespace boundaries. This is the only cases
      where we clearly want to reset nf_trace and is also what the
      original patch intended to fix.
    
    Add a new function nf_reset_trace() and use it in dev_forward_skb() to
    fix this properly.
    
    Signed-off-by: Patrick McHardy <kaber@trash.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ba12001651d677a8742aa465d3996885d2568f98
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Wed Apr 3 16:14:47 2013 +0000

    af_unix: If we don't care about credentials coallesce all messages
    
    [ Upstream commit 0e82e7f6dfeec1013339612f74abc2cdd29d43d2 ]
    
    It was reported that the following LSB test case failed
    https://lsbbugs.linuxfoundation.org/attachment.cgi?id=2144 because we
    were not coallescing unix stream messages when the application was
    expecting us to.
    
    The problem was that the first send was before the socket was accepted
    and thus sock->sk_socket was NULL in maybe_add_creds, and the second
    send after the socket was accepted had a non-NULL value for sk->socket
    and thus we could tell the credentials were not needed so we did not
    bother.
    
    The unnecessary credentials on the first message cause
    unix_stream_recvmsg to start verifying that all messages had the same
    credentials before coallescing and then the coallescing failed because
    the second message had no credentials.
    
    Ignoring credentials when we don't care in unix_stream_recvmsg fixes a
    long standing pessimization which would fail to coallesce messages when
    reading from a unix stream socket if the senders were different even if
    we did not care about their credentials.
    
    I have tested this and verified that the in the LSB test case mentioned
    above that the messages do coallesce now, while the were failing to
    coallesce without this change.
    
    Reported-by: Karel Srot <ksrot@redhat.com>
    Reported-by: Ding Tianhong <dingtianhong@huawei.com>
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a11e5fe4e27757d6316f25119ec02d4b3ab199a
Author: nikolay@redhat.com <nikolay@redhat.com>
Date:   Thu Apr 11 09:18:56 2013 +0000

    bonding: IFF_BONDING is not stripped on enslave failure
    
    [ Upstream commit b6a5a7b9a528a8b4c8bec940b607c5dd9102b8cc ]
    
    While enslaving a new device and after IFF_BONDING flag is set, in case
    of failure it is not stripped from the device's priv_flags while
    cleaning up, which could lead to other problems.
    Cleaning at err_close because the flag is set after dev_open().
    
    v2: no change
    
    Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 643094adbef902c4a1f5a544f1f8eb8512e7ff8c
Author: nikolay@redhat.com <nikolay@redhat.com>
Date:   Sat Apr 6 00:54:38 2013 +0000

    bonding: fix bonding_masters race condition in bond unloading
    
    [ Upstream commit 69b0216ac255f523556fa3d4ff030d857eaaa37f ]
    
    While the bonding module is unloading, it is considered that after
    rtnl_link_unregister all bond devices are destroyed but since no
    synchronization mechanism exists, a new bond device can be created
    via bonding_masters before unregister_pernet_subsys which would
    lead to multiple problems (e.g. NULL pointer dereference, wrong RIP,
    list corruption).
    
    This patch fixes the issue by removing any bond devices left in the
    netns after bonding_masters is removed from sysfs.
    
    Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
    Acked-by: Veaceslav Falico <vfalico@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 74595d06f51d68bbc25c5864d15566ea5049a33a
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date:   Tue Apr 2 14:36:46 2013 +0000

    atl1e: limit gso segment size to prevent generation of wrong ip length fields
    
    [ Upstream commit 31d1670e73f4911fe401273a8f576edc9c2b5fea ]
    
    The limit of 0x3c00 is taken from the windows driver.
    
    Suggested-by: Huang, Xiong <xiong@qca.qualcomm.com>
    Cc: Huang, Xiong <xiong@qca.qualcomm.com>
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 617f13b4194b6aad612733a932bc89d883d9325e
Author: Vlad Yasevich <vyasevic@redhat.com>
Date:   Tue Apr 2 17:10:07 2013 -0400

    net: count hw_addr syncs so that unsync works properly.
    
    [ Upstream commit 4543fbefe6e06a9e40d9f2b28d688393a299f079 ]
    
    A few drivers use dev_uc_sync/unsync to synchronize the
    address lists from master down to slave/lower devices.  In
    some cases (bond/team) a single address list is synched down
    to multiple devices.  At the time of unsync, we have a leak
    in these lower devices, because "synced" is treated as a
    boolean and the address will not be unsynced for anything after
    the first device/call.
    
    Treat "synced" as a count (same as refcount) and allow all
    unsync calls to work.
    
    Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ef95e3d5d7325b87ca22c4aa72710ac152315559
Author: Balakumaran Kannan <kumaran.4353@gmail.com>
Date:   Tue Apr 2 16:15:05 2013 +0530

    net IPv6 : Fix broken IPv6 routing table after loopback down-up
    
    [ Upstream commit 25fb6ca4ed9cad72f14f61629b68dc03c0d9713f ]
    
    IPv6 Routing table becomes broken once we do ifdown, ifup of the loopback(lo)
    interface. After down-up, routes of other interface's IPv6 addresses through
    'lo' are lost.
    
    IPv6 addresses assigned to all interfaces are routed through 'lo' for internal
    communication. Once 'lo' is down, those routing entries are removed from routing
    table. But those removed entries are not being re-created properly when 'lo' is
    brought up. So IPv6 addresses of other interfaces becomes unreachable from the
    same machine. Also this breaks communication with other machines because of
    NDISC packet processing failure.
    
    This patch fixes this issue by reading all interface's IPv6 addresses and adding
    them to IPv6 routing table while bringing up 'lo'.
    
    ==Testing==
    Before applying the patch:
    $ route -A inet6
    Kernel IPv6 routing table
    Destination                    Next Hop                   Flag Met Ref Use If
    2000::20/128                   ::                         U    256 0     0 eth0
    fe80::/64                      ::                         U    256 0     0 eth0
    ::/0                           ::                         !n   -1  1     1 lo
    ::1/128                        ::                         Un   0   1     0 lo
    2000::20/128                   ::                         Un   0   1     0 lo
    fe80::xxxx:xxxx:xxxx:xxxx/128  ::                         Un   0   1     0 lo
    ff00::/8                       ::                         U    256 0     0 eth0
    ::/0                           ::                         !n   -1  1     1 lo
    $ sudo ifdown lo
    $ sudo ifup lo
    $ route -A inet6
    Kernel IPv6 routing table
    Destination                    Next Hop                   Flag Met Ref Use If
    2000::20/128                   ::                         U    256 0     0 eth0
    fe80::/64                      ::                         U    256 0     0 eth0
    ::/0                           ::                         !n   -1  1     1 lo
    ::1/128                        ::                         Un   0   1     0 lo
    ff00::/8                       ::                         U    256 0     0 eth0
    ::/0                           ::                         !n   -1  1     1 lo
    $
    
    After applying the patch:
    $ route -A inet6
    Kernel IPv6 routing
    table
    Destination                    Next Hop                   Flag Met Ref Use If
    2000::20/128                   ::                         U    256 0     0 eth0
    fe80::/64                      ::                         U    256 0     0 eth0
    ::/0                           ::                         !n   -1  1     1 lo
    ::1/128                        ::                         Un   0   1     0 lo
    2000::20/128                   ::                         Un   0   1     0 lo
    fe80::xxxx:xxxx:xxxx:xxxx/128  ::                         Un   0   1     0 lo
    ff00::/8                       ::                         U    256 0     0 eth0
    ::/0                           ::                         !n   -1  1     1 lo
    $ sudo ifdown lo
    $ sudo ifup lo
    $ route -A inet6
    Kernel IPv6 routing table
    Destination                    Next Hop                   Flag Met Ref Use If
    2000::20/128                   ::                         U    256 0     0 eth0
    fe80::/64                      ::                         U    256 0     0 eth0
    ::/0                           ::                         !n   -1  1     1 lo
    ::1/128                        ::                         Un   0   1     0 lo
    2000::20/128                   ::                         Un   0   1     0 lo
    fe80::xxxx:xxxx:xxxx:xxxx/128  ::                         Un   0   1     0 lo
    ff00::/8                       ::                         U    256 0     0 eth0
    ::/0                           ::                         !n   -1  1     1 lo
    $
    
    Signed-off-by: Balakumaran Kannan <Balakumaran.Kannan@ap.sony.com>
    Signed-off-by: Maruthi Thotad <Maruthi.Thotad@ap.sony.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 815b1018620edb2f86fc7a7740b9a0e726446929
Author: Vasily Averin <vvs@parallels.com>
Date:   Mon Apr 1 03:01:32 2013 +0000

    cbq: incorrect processing of high limits
    
    [ Upstream commit f0f6ee1f70c4eaab9d52cf7d255df4bd89f8d1c2 ]
    
    currently cbq works incorrectly for limits > 10% real link bandwidth,
    and practically does not work for limits > 50% real link bandwidth.
    Below are results of experiments taken on 1 Gbit link
    
     In shaper | Actual Result
    -----------+---------------
      100M     | 108 Mbps
      200M     | 244 Mbps
      300M     | 412 Mbps
      500M     | 893 Mbps
    
    This happen because of q->now changes incorrectly in cbq_dequeue():
    when it is called before real end of packet transmitting,
    L2T is greater than real time delay, q_now gets an extra boost
    but never compensate it.
    
    To fix this problem we prevent change of q->now until its synchronization
    with real time.
    
    Signed-off-by: Vasily Averin <vvs@openvz.org>
    Reviewed-by: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7b806e764b487cf1f348d1e4377f99853935ff7c
Author: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Date:   Tue Apr 9 10:07:19 2013 +0800

    netrom: fix invalid use of sizeof in nr_recvmsg()
    
    [ Upstream commit c802d759623acbd6e1ee9fbdabae89159a513913 ]
    
    sizeof() when applied to a pointer typed expression gives the size of the
    pointer, not that of the pointed data.
    Introduced by commit 3ce5ef(netrom: fix info leak via msg_name in nr_recvmsg)
    
    Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e979f5408b145c0d2b0bf6622952c09a43bcd23a
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 01:52:00 2013 +0000

    tipc: fix info leaks via msg_name in recv_msg/recv_stream
    
    [ Upstream commit 60085c3d009b0df252547adb336d1ccca5ce52ec ]
    
    The code in set_orig_addr() does not initialize all of the members of
    struct sockaddr_tipc when filling the sockaddr info -- namely the union
    is only partly filled. This will make recv_msg() and recv_stream() --
    the only users of this function -- leak kernel stack memory as the
    msg_name member is a local variable in net/socket.c.
    
    Additionally to that both recv_msg() and recv_stream() fail to update
    the msg_namelen member to 0 while otherwise returning with 0, i.e.
    "success". This is the case for, e.g., non-blocking sockets. This will
    lead to a 128 byte kernel stack leak in net/socket.c.
    
    Fix the first issue by initializing the memory of the union with
    memset(0). Fix the second one by setting msg_namelen to 0 early as it
    will be updated later if we're going to fill the msg_name member.
    
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Jon Maloy <jon.maloy@ericsson.com>
    Cc: Allan Stephens <allan.stephens@windriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1a4dc01afc19f4a30c015ef62a43930241ee15b1
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 01:51:59 2013 +0000

    rose: fix info leak via msg_name in rose_recvmsg()
    
    [ Upstream commit 4a184233f21645cf0b719366210ed445d1024d72 ]
    
    The code in rose_recvmsg() does not initialize all of the members of
    struct sockaddr_rose/full_sockaddr_rose when filling the sockaddr info.
    Nor does it initialize the padding bytes of the structure inserted by
    the compiler for alignment. This will lead to leaking uninitialized
    kernel stack bytes in net/socket.c.
    
    Fix the issue by initializing the memory used for sockaddr info with
    memset(0).
    
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1091d7dddb9f0fc287bf17c5f6c7859fe0bc50b3
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 01:51:58 2013 +0000

    NFC: llcp: fix info leaks via msg_name in llcp_sock_recvmsg()
    
    [ Upstream commit d26d6504f23e803824e8ebd14e52d4fc0a0b09cb ]
    
    The code in llcp_sock_recvmsg() does not initialize all the members of
    struct sockaddr_nfc_llcp when filling the sockaddr info. Nor does it
    initialize the padding bytes of the structure inserted by the compiler
    for alignment.
    
    Also, if the socket is in state LLCP_CLOSED or is shutting down during
    receive the msg_namelen member is not updated to 0 while otherwise
    returning with 0, i.e. "success". The msg_namelen update is also
    missing for stream and seqpacket sockets which don't fill the sockaddr
    info.
    
    Both issues lead to the fact that the code will leak uninitialized
    kernel stack bytes in net/socket.c.
    
    Fix the first issue by initializing the memory used for sockaddr info
    with memset(0). Fix the second one by setting msg_namelen to 0 early.
    It will be updated later if we're going to fill the msg_name member.
    
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Lauro Ramos Venancio <lauro.venancio@openbossa.org>
    Cc: Aloisio Almeida Jr <aloisio.almeida@openbossa.org>
    Cc: Samuel Ortiz <sameo@linux.intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cd5e3d9ff117b6cff7a82b076be20dc91eec3f4f
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 01:51:57 2013 +0000

    netrom: fix info leak via msg_name in nr_recvmsg()
    
    [ Upstream commits 3ce5efad47b62c57a4f5c54248347085a750ce0e and
      c802d759623acbd6e1ee9fbdabae89159a513913 ]
    
    In case msg_name is set the sockaddr info gets filled out, as
    requested, but the code fails to initialize the padding bytes of
    struct sockaddr_ax25 inserted by the compiler for alignment. Also
    the sax25_ndigis member does not get assigned, leaking four more
    bytes.
    
    Both issues lead to the fact that the code will leak uninitialized
    kernel stack bytes in net/socket.c.
    
    Fix both issues by initializing the memory with memset(0).
    
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 40aea043862dd46aa865587223e084da2e3e37cf
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 01:51:56 2013 +0000

    llc: Fix missing msg_namelen update in llc_ui_recvmsg()
    
    [ Upstream commit c77a4b9cffb6215a15196ec499490d116dfad181 ]
    
    For stream sockets the code misses to update the msg_namelen member
    to 0 and therefore makes net/socket.c leak the local, uninitialized
    sockaddr_storage variable to userland -- 128 bytes of kernel stack
    memory. The msg_namelen update is also missing for datagram sockets
    in case the socket is shutting down during receive.
    
    Fix both issues by setting msg_namelen to 0 early. It will be
    updated later if we're going to fill the msg_name member.
    
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dbd99572c687037ca7ddb31df2d7fd364732c670
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 01:51:54 2013 +0000

    iucv: Fix missing msg_namelen update in iucv_sock_recvmsg()
    
    [ Upstream commit a5598bd9c087dc0efc250a5221e5d0e6f584ee88 ]
    
    The current code does not fill the msg_name member in case it is set.
    It also does not set the msg_namelen member to 0 and therefore makes
    net/socket.c leak the local, uninitialized sockaddr_storage variable
    to userland -- 128 bytes of kernel stack memory.
    
    Fix that by simply setting msg_namelen to 0 as obviously nobody cared
    about iucv_sock_recvmsg() not filling the msg_name in case it was set.
    
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Ursula Braun <ursula.braun@de.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d3dd6298cdf289b410c030f0d329020cffd85a1d
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 01:51:53 2013 +0000

    irda: Fix missing msg_namelen update in irda_recvmsg_dgram()
    
    [ Upstream commit 5ae94c0d2f0bed41d6718be743985d61b7f5c47d ]
    
    The current code does not fill the msg_name member in case it is set.
    It also does not set the msg_namelen member to 0 and therefore makes
    net/socket.c leak the local, uninitialized sockaddr_storage variable
    to userland -- 128 bytes of kernel stack memory.
    
    Fix that by simply setting msg_namelen to 0 as obviously nobody cared
    about irda_recvmsg_dgram() not filling the msg_name in case it was
    set.
    
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Samuel Ortiz <samuel@sortiz.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3300687d7ebb7a8abd9945843629b09194d97430
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 01:51:52 2013 +0000

    caif: Fix missing msg_namelen update in caif_seqpkt_recvmsg()
    
    [ Upstream commit 2d6fbfe733f35c6b355c216644e08e149c61b271 ]
    
    The current code does not fill the msg_name member in case it is set.
    It also does not set the msg_namelen member to 0 and therefore makes
    net/socket.c leak the local, uninitialized sockaddr_storage variable
    to userland -- 128 bytes of kernel stack memory.
    
    Fix that by simply setting msg_namelen to 0 as obviously nobody cared
    about caif_seqpkt_recvmsg() not filling the msg_name in case it was
    set.
    
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Sjur Braendeland <sjur.brandeland@stericsson.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2d97f68d03180ad0a47fdb7c02f0fecdac9ad9a7
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 01:51:50 2013 +0000

    Bluetooth: RFCOMM - Fix missing msg_namelen update in rfcomm_sock_recvmsg()
    
    [ Upstream commit e11e0455c0d7d3d62276a0c55d9dfbc16779d691 ]
    
    If RFCOMM_DEFER_SETUP is set in the flags, rfcomm_sock_recvmsg() returns
    early with 0 without updating the possibly set msg_namelen member. This,
    in turn, leads to a 128 byte kernel stack leak in net/socket.c.
    
    Fix this by updating msg_namelen in this case. For all other cases it
    will be handled in bt_sock_stream_recvmsg().
    
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Marcel Holtmann <marcel@holtmann.org>
    Cc: Gustavo Padovan <gustavo@padovan.org>
    Cc: Johan Hedberg <johan.hedberg@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a776cc3f3ae0b7d0f6137f4dc98470e3d4bb52d0
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 01:51:49 2013 +0000

    Bluetooth: fix possible info leak in bt_sock_recvmsg()
    
    [ Upstream commit 4683f42fde3977bdb4e8a09622788cc8b5313778 ]
    
    In case the socket is already shutting down, bt_sock_recvmsg() returns
    with 0 without updating msg_namelen leading to net/socket.c leaking the
    local, uninitialized sockaddr_storage variable to userland -- 128 bytes
    of kernel stack memory.
    
    Fix this by moving the msg_namelen assignment in front of the shutdown
    test.
    
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Marcel Holtmann <marcel@holtmann.org>
    Cc: Gustavo Padovan <gustavo@padovan.org>
    Cc: Johan Hedberg <johan.hedberg@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 03730954ad1dd8b5027565c1e20b427d5be5a66f
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 01:51:48 2013 +0000

    ax25: fix info leak via msg_name in ax25_recvmsg()
    
    [ Upstream commit ef3313e84acbf349caecae942ab3ab731471f1a1 ]
    
    When msg_namelen is non-zero the sockaddr info gets filled out, as
    requested, but the code fails to initialize the padding bytes of struct
    sockaddr_ax25 inserted by the compiler for alignment. Additionally the
    msg_namelen value is updated to sizeof(struct full_sockaddr_ax25) but is
    not always filled up to this size.
    
    Both issues lead to the fact that the code will leak uninitialized
    kernel stack bytes in net/socket.c.
    
    Fix both issues by initializing the memory with memset(0).
    
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e242b8561d006aa66c12ab997cc3d729cf2c9ca
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 01:51:47 2013 +0000

    atm: update msg_namelen in vcc_recvmsg()
    
    [ Upstream commit 9b3e617f3df53822345a8573b6d358f6b9e5ed87 ]
    
    The current code does not fill the msg_name member in case it is set.
    It also does not set the msg_namelen member to 0 and therefore makes
    net/socket.c leak the local, uninitialized sockaddr_storage variable
    to userland -- 128 bytes of kernel stack memory.
    
    Fix that by simply setting msg_namelen to 0 as obviously nobody cared
    about vcc_recvmsg() not filling the msg_name in case it was set.
    
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bf6f841f7fde2731ea39698064a81492ce777fa6
Author: David S. Miller <davem@davemloft.net>
Date:   Fri Apr 19 17:26:26 2013 -0400

    sparc64: Fix race in TLB batch processing.
    
    [ Commits f36391d2790d04993f48da6a45810033a2cdf847 and
      f0af97070acbad5d6a361f485828223a4faaa0ee upstream. ]
    
    As reported by Dave Kleikamp, when we emit cross calls to do batched
    TLB flush processing we have a race because we do not synchronize on
    the sibling cpus completing the cross call.
    
    So meanwhile the TLB batch can be reset (tb->tlb_nr set to zero, etc.)
    and either flushes are missed or flushes will flush the wrong
    addresses.
    
    Fix this by using generic infrastructure to synchonize on the
    completion of the cross call.
    
    This first required getting the flush_tlb_pending() call out from
    switch_to() which operates with locks held and interrupts disabled.
    The problem is that smp_call_function_many() cannot be invoked with
    IRQs disabled and this is explicitly checked for with WARN_ON_ONCE().
    
    We get the batch processing outside of locked IRQ disabled sections by
    using some ideas from the powerpc port. Namely, we only batch inside
    of arch_{enter,leave}_lazy_mmu_mode() calls.  If we're not in such a
    region, we flush TLBs synchronously.
    
    1) Get rid of xcall_flush_tlb_pending and per-cpu type
       implementations.
    
    2) Do TLB batch cross calls instead via:
    
    	smp_call_function_many()
    		tlb_pending_func()
    			__flush_tlb_pending()
    
    3) Batch only in lazy mmu sequences:
    
    	a) Add 'active' member to struct tlb_batch
    	b) Define __HAVE_ARCH_ENTER_LAZY_MMU_MODE
    	c) Set 'active' in arch_enter_lazy_mmu_mode()
    	d) Run batch and clear 'active' in arch_leave_lazy_mmu_mode()
    	e) Check 'active' in tlb_batch_add_one() and do a synchronous
               flush if it's clear.
    
    4) Add infrastructure for synchronous TLB page flushes.
    
    	a) Implement __flush_tlb_page and per-cpu variants, patch
    	   as needed.
    	b) Likewise for xcall_flush_tlb_page.
    	c) Implement smp_flush_tlb_page() to invoke the cross-call.
    	d) Wire up global_flush_tlb_page() to the right routine based
               upon CONFIG_SMP
    
    5) It turns out that singleton batches are very common, 2 out of every
       3 batch flushes have only a single entry in them.
    
       The batch flush waiting is very expensive, both because of the poll
       on sibling cpu completeion, as well as because passing the tlb batch
       pointer to the sibling cpus invokes a shared memory dereference.
    
       Therefore, in flush_tlb_pending(), if there is only one entry in
       the batch perform a completely asynchronous global_flush_tlb_page()
       instead.
    
    Reported-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Acked-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c61642cce0247175489666d90ebd59f8a04e7c76
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Fri Apr 26 13:48:53 2013 +0200

    TTY: fix atime/mtime regression
    
    commit 37b7f3c76595e23257f61bd80b223de8658617ee upstream.
    
    In commit b0de59b5733d ("TTY: do not update atime/mtime on read/write")
    we removed timestamps from tty inodes to fix a security issue and waited
    if something breaks.  Well, 'w', the utility to find out logged users
    and their inactivity time broke.  It shows that users are inactive since
    the time they logged in.
    
    To revert to the old behaviour while still preventing attackers to
    guess the password length, we update the timestamps in one-minute
    intervals by this patch.
    
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ab8db7b9c2e0a399e65a95999e0794a85c63975
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Fri Feb 15 15:25:05 2013 +0100

    TTY: do not update atime/mtime on read/write
    
    commit b0de59b5733d18b0d1974a060860a8b5c1b36a2e upstream.
    
    On http://vladz.devzero.fr/013_ptmx-timing.php, we can see how to find
    out length of a password using timestamps of /dev/ptmx. It is
    documented in "Timing Analysis of Keystrokes and Timing Attacks on
    SSH". To avoid that problem, do not update time when reading
    from/writing to a TTY.
    
    I am afraid of regressions as this is a behavior we have since 0.97
    and apps may expect the time to be current, e.g. for monitoring
    whether there was a change on the TTY. Now, there is no change. So
    this would better have a lot of testing before it goes upstream.
    
    References: CVE-2013-0160
    
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6bcd3002a29b597e2774a733b74c204c1b344026
Author: Zhao Hongjiang <zhaohongjiang@huawei.com>
Date:   Fri Apr 26 11:03:53 2013 +0800

    aio: fix possible invalid memory access when DEBUG is enabled
    
    commit 91d80a84bbc8f28375cca7e65ec666577b4209ad upstream.
    
    dprintk() shouldn't access @ring after it's unmapped.
    
    Signed-off-by: Zhao Hongjiang <zhaohongjiang@huawei.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>