commit 00b90e79ccf06fc1c7357e52e028435f8ec1cf11 Author: Willy Tarreau Date: Wed Jun 3 17:25:25 2015 +0200 Linux 2.6.32.67 commit a8226a63842840c1e7890a86d076e30670744f03 Author: Junling Zheng 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 Signed-off-by: Hanbing Xu Cc: Li Zefan Cc: Al Viro Cc: David Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Willy Tarreau commit cb162b71b1c49ccc6f13ae2b74ed4703ba86d872 Author: Willy Tarreau 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" > To: "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 Signed-off-by: Willy Tarreau