From patchwork Fri Sep 2 03:41:38 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mitsuo Hayasaka X-Patchwork-Id: 113029 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 87394B6F71 for ; Fri, 2 Sep 2011 13:37:13 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753037Ab1IBDgn (ORCPT ); Thu, 1 Sep 2011 23:36:43 -0400 Received: from mail7.hitachi.co.jp ([133.145.228.42]:57872 "EHLO mail7.hitachi.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753507Ab1IBDgl (ORCPT ); Thu, 1 Sep 2011 23:36:41 -0400 Received: from mlsv3.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id 595C837AC4; Fri, 2 Sep 2011 12:36:39 +0900 (JST) Received: from mfilter04.hitachi.co.jp by mlsv3.hitachi.co.jp (8.13.1/8.13.1) id p823adwU008167; Fri, 2 Sep 2011 12:36:39 +0900 Received: from vshuts4.hitachi.co.jp (vshuts4.hitachi.co.jp [10.201.6.80]) by mfilter04.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id p823acbK027860; Fri, 2 Sep 2011 12:36:38 +0900 X-AuditID: b753bd60-a14abba0000019f4-01-4e604f463602 Received: from hsdlmain.sdl.hitachi.co.jp (unknown [133.144.14.194]) by vshuts4.hitachi.co.jp (Symantec Mail Security) with ESMTP id EFFAC204372; Fri, 2 Sep 2011 12:36:37 +0900 (JST) Received: from hsdlvgate2.sdl.hitachi.co.jp by hsdlmain.sdl.hitachi.co.jp (8.13.1/3.7W11021512) id p823abSh017866; Fri, 2 Sep 2011 12:36:37 +0900 X-AuditID: b753bd60-a14abba0000019f4-01-4e604f463602 Received: from sdl99w.sdl.hitachi.co.jp (sdl99w.sdl.hitachi.co.jp [133.144.14.250]) by hsdlvgate2.sdl.hitachi.co.jp (Symantec Mail Security) with ESMTP id 5BE1D236561; Fri, 2 Sep 2011 12:36:37 +0900 (JST) Received: from ltc219.sdl.hitachi.co.jp (cb10033149.sdl.hitachi.co.jp [10.232.10.18]) by sdl99w.sdl.hitachi.co.jp (Postfix) with ESMTP id 8AF491254FD; Fri, 2 Sep 2011 12:36:28 +0900 (JST) From: Mitsuo Hayasaka Subject: [PATCH net-next-2.6 ] Fix overflow of socket buffer in sunrpc To: Trond Myklebust , "J. Bruce Fields" , Neil Brown , "David S. Miller" Cc: linux-nfs@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, yrl.pp-manager.tt@hitachi.com, Mitsuo Hayasaka , Trond Myklebust , "J. Bruce Fields" , Neil Brown , "David S. Miller" Date: Fri, 02 Sep 2011 12:41:38 +0900 Message-ID: <20110902034138.22595.9759.stgit@ltc219.sdl.hitachi.co.jp> User-Agent: StGIT/0.14.3 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org The sk_sndbuf and sk_rcvbuf fields of struct sock are sizes of send and receive socket buffers respectively, and are defined as integer. The sunrpc which is used in NFSD and any other applications can change them via svc_sock_setbufsize(). It, however, sets them as unsigned integer and may cause overflow of integer. This leads to a degradation of networking capability. This patch adds integer-overflow check into svc_sock_setbufsize() before both fields are set, and limits their maximum sizes to INT_MAX. Signed-off-by: Mitsuo Hayasaka Cc: Trond Myklebust Cc: "J. Bruce Fields" Cc: Neil Brown Cc: "David S. Miller" --- net/sunrpc/svcsock.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c index 767d494..bd66775 100644 --- a/net/sunrpc/svcsock.c +++ b/net/sunrpc/svcsock.c @@ -54,6 +54,7 @@ #include "sunrpc.h" #define RPCDBG_FACILITY RPCDBG_SVCXPRT +#define MAX_SKBUFSIZ INT_MAX static struct svc_sock *svc_setup_socket(struct svc_serv *, struct socket *, @@ -435,6 +436,11 @@ static void svc_sock_setbufsize(struct socket *sock, unsigned int snd, * on not having CAP_SYS_RESOURCE or similar, we go direct... * DaveM said I could! */ + if (snd > MAX_SKBUFSIZ/2) + snd = MAX_SKBUFSIZ/2; + if (rcv > MAX_SKBUFSIZ/2) + rcv = MAX_SKBUFSIZ/2; + lock_sock(sock->sk); sock->sk->sk_sndbuf = snd * 2; sock->sk->sk_rcvbuf = rcv * 2;