From patchwork Tue Aug 23 11:21:28 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Layton X-Patchwork-Id: 1088082 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by demeter2.kernel.org (8.14.4/8.14.4) with ESMTP id p7NBLaM1013325 for ; Tue, 23 Aug 2011 11:21:37 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752435Ab1HWLVg (ORCPT ); Tue, 23 Aug 2011 07:21:36 -0400 Received: from mail-gy0-f174.google.com ([209.85.160.174]:43114 "EHLO mail-gy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751065Ab1HWLVf (ORCPT ); Tue, 23 Aug 2011 07:21:35 -0400 Received: by gya6 with SMTP id 6so4228912gya.19 for ; Tue, 23 Aug 2011 04:21:35 -0700 (PDT) Received: by 10.101.144.18 with SMTP id w18mr3505731ann.133.1314098494691; Tue, 23 Aug 2011 04:21:34 -0700 (PDT) Received: from salusa.poochiereds.net (cpe-075-177-182-191.nc.res.rr.com [75.177.182.191]) by mx.google.com with ESMTPS id d33sm48355ano.35.2011.08.23.04.21.32 (version=SSLv3 cipher=OTHER); Tue, 23 Aug 2011 04:21:33 -0700 (PDT) From: Jeff Layton To: smfrench@gmail.com Cc: linux-cifs@vger.kernel.org, dcl@hppine99.gbr.hp.com Subject: [PATCH] cifs: fix possible memory corruption in CIFSFindNext Date: Tue, 23 Aug 2011 07:21:28 -0400 Message-Id: <1314098488-1547-1-git-send-email-jlayton@redhat.com> X-Mailer: git-send-email 1.7.6 Sender: linux-cifs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-cifs@vger.kernel.org X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.6 (demeter2.kernel.org [140.211.167.43]); Tue, 23 Aug 2011 11:21:37 +0000 (UTC) The name_len variable in CIFSFindNext is a signed int that gets set to the resume_name_len in the cifs_search_info. The resume_name_len however is unsigned and for some infolevels is populated directly from a 32 bit value sent by the server. If the server sends a very large value for this, then that value could look negative when converted to a signed int. That would make that value pass the PATH_MAX check later in CIFSFindNext. The name_len would then be used as a length value for a memcpy. It would then be treated as unsigned again, and the memcpy scribbles over a ton of memory. Fix this by making the name_len an unsigned value in CIFSFindNext. Cc: Reported-by: Darren Lavender Signed-off-by: Jeff Layton --- fs/cifs/cifssmb.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/fs/cifs/cifssmb.c b/fs/cifs/cifssmb.c index f4d0988..950464d 100644 --- a/fs/cifs/cifssmb.c +++ b/fs/cifs/cifssmb.c @@ -4089,7 +4089,8 @@ int CIFSFindNext(const int xid, struct cifs_tcon *tcon, T2_FNEXT_RSP_PARMS *parms; char *response_data; int rc = 0; - int bytes_returned, name_len; + int bytes_returned; + unsigned int name_len; __u16 params, byte_count; cFYI(1, "In FindNext");