commit 00b90e79ccf06fc1c7357e52e028435f8ec1cf11
Author: Willy Tarreau <w@1wt.eu>
Date:   Wed Jun 3 17:25:25 2015 +0200

    Linux 2.6.32.67

commit a8226a63842840c1e7890a86d076e30670744f03
Author: Junling Zheng <zhengjunling@huawei.com>
Date:   Mon Jun 1 09:28:00 2015 +0000

    net: socket: Fix the wrong returns for recvmsg and sendmsg
    
    Based on 08adb7dabd4874cc5666b4490653b26534702ce0 upstream.
    
    We found that after v3.10.73, recvmsg might return -EFAULT while -EINVAL
    was expected.
    
    We tested it through the recvmsg01 testcase come from LTP testsuit. It set
    msg->msg_namelen to -1 and the recvmsg syscall returned errno 14, which is
    unexpected (errno 22 is expected):
    
    recvmsg01    4  TFAIL  :  invalid socket length ; returned -1 (expected -1),
    errno 14 (expected 22)
    
    Linux mainline has no this bug for commit 08adb7dab fixes it accidentally.
    However, it is too large and complex to be backported to LTS 3.10.
    
    Commit 281c9c36 (net: compat: Update get_compat_msghdr() to match
    copy_msghdr_from_user() behaviour) made get_compat_msghdr() return
    error if msg_sys->msg_namelen was negative, which changed the behaviors
    of recvmsg and sendmsg syscall in a lib32 system:
    
    Before commit 281c9c36, get_compat_msghdr() wouldn't fail and it would
    return -EINVAL in move_addr_to_user() or somewhere if msg_sys->msg_namelen
    was invalid and then syscall returned -EINVAL, which is correct.
    
    And now, when msg_sys->msg_namelen is negative, get_compat_msghdr() will
    fail and wants to return -EINVAL, however, the outer syscall will return
    -EFAULT directly, which is unexpected.
    
    This patch gets the return value of get_compat_msghdr() as well as
    copy_msghdr_from_user(), then returns this expected value if
    get_compat_msghdr() fails.
    
    Fixes: 281c9c36 (net: compat: Update get_compat_msghdr() to match copy_msghdr_from_user() behaviour)
    Signed-off-by: Junling Zheng <zhengjunling@huawei.com>
    Signed-off-by: Hanbing Xu <xuhanbing@huawei.com>
    Cc: Li Zefan <lizefan@huawei.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: David Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>

commit cb162b71b1c49ccc6f13ae2b74ed4703ba86d872
Author: Willy Tarreau <w@1wt.eu>
Date:   Wed Jun 3 17:03:26 2015 +0200

    net: fix incorrect backport of tcp_send_fin in 2.6.32.66
    
    Eric forwarded this bug report happening since 2.6.32.66, found that the
    backport of commit 845704a5 ("tcp: avoid looping in tcp_send_fin()") was
    incorrect and proposed this patch to fix it. The bug was also reported by
    starlight.2015q2@binnacle.cx who confirmed the fix.
    
    > Date: Fri, 29 May 2015 09:12:45 +0000
    > From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
    > To: "shemminger@linux-foundation.org" <shemminger@linux-foundation.org>
    > Subject: [Bug 99161] New: 2.6.32.66 PPC Oops in tcp_send_fin
    >
    >
    > https://bugzilla.kernel.org/show_bug.cgi?id=99161
    >
    >             Bug ID: 99161
    >            Summary: 2.6.32.66 PPC Oops in tcp_send_fin
    >            Product: Networking
    >            Version: 2.5
    >     Kernel Version: 2.6.32.66
    >           Hardware: PPC-32
    >                 OS: Linux
    >               Tree: Mainline
    >             Status: NEW
    >           Severity: normal
    >           Priority: P1
    >          Component: IPV4
    >           Assignee: shemminger@linux-foundation.org
    >           Reporter: varenet@parisc-linux.org
    >         Regression: No
    >
    > I just updated my trusty old PPC box to longterm 2.6.32.66 (was running .65
    > before that with zero issue) and it started spewing oopses at me like hell
    > broke loose. This machine is primarily used as a DNS and MX (albeit under low
    > pressure).
    (...)
    
    Cc: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>