From patchwork Fri Apr 20 08:38:23 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stefan Bader X-Patchwork-Id: 153958 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from chlorine.canonical.com (chlorine.canonical.com [91.189.94.204]) by ozlabs.org (Postfix) with ESMTP id 82C08B7043 for ; Fri, 20 Apr 2012 18:38:34 +1000 (EST) Received: from localhost ([127.0.0.1] helo=chlorine.canonical.com) by chlorine.canonical.com with esmtp (Exim 4.71) (envelope-from ) id 1SL9MI-0005Pl-9I; Fri, 20 Apr 2012 08:38:26 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by chlorine.canonical.com with esmtp (Exim 4.71) (envelope-from ) id 1SL9MG-0005Pg-HS for kernel-team@lists.ubuntu.com; Fri, 20 Apr 2012 08:38:24 +0000 Received: from p5b2e4d2e.dip.t-dialin.net ([91.46.77.46] helo=canonical.com) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1SL9MG-0001WK-BV for kernel-team@lists.ubuntu.com; Fri, 20 Apr 2012 08:38:24 +0000 From: Stefan Bader To: kernel-team@lists.ubuntu.com Subject: [CVE-2012-1090] natty, natty/ti-omap4 Date: Fri, 20 Apr 2012 10:38:23 +0200 Message-Id: <1334911103-3072-1-git-send-email-stefan.bader@canonical.com> X-Mailer: git-send-email 1.7.9.5 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.13 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: kernel-team-bounces@lists.ubuntu.com Errors-To: kernel-team-bounces@lists.ubuntu.com A flaw was discovered in the Linux kernel's cifs file system. An unprivileged local user could exploit this flaw to crash the system leading to a denial of service. I believe this was introduced somewhere in 2.6.30, so Hardy is not affected. Fixes have reached Oneiric and Precise via upstream stable. So proposing for Natty and the ti-omap4 branch there. -Stefan From 35e7104ae389ba5f952163f4c8c678e78269dbd9 Mon Sep 17 00:00:00 2001 From: Jeff Layton Date: Thu, 23 Feb 2012 09:37:45 -0500 Subject: [PATCH] cifs: fix dentry refcount leak when opening a FIFO on lookup The cifs code will attempt to open files on lookup under certain circumstances. What happens though if we find that the file we opened was actually a FIFO or other special file? Currently, the open filehandle just ends up being leaked leading to a dentry refcount mismatch and oops on umount. Fix this by having the code close the filehandle on the server if it turns out not to be a regular file. While we're at it, change this spaghetti if statement into a switch too. Cc: stable@vger.kernel.org Reported-by: CAI Qian Tested-by: CAI Qian Reviewed-by: Shirish Pargaonkar Signed-off-by: Jeff Layton Signed-off-by: Steve French BugLink: http://bugs.launchpad.net/bugs/947997 CVE-2012-1090 (cherry-picked from 5bccda0ebc7c0331b81ac47d39e4b920b198b2cd upstream) Signed-off-by: Stefan Bader Acked-by: Leann Ogasawara --- fs/cifs/dir.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/fs/cifs/dir.c b/fs/cifs/dir.c index dd5f229..625c53d 100644 --- a/fs/cifs/dir.c +++ b/fs/cifs/dir.c @@ -573,10 +573,26 @@ cifs_lookup(struct inode *parent_dir_inode, struct dentry *direntry, * If either that or op not supported returned, follow * the normal lookup. */ - if ((rc == 0) || (rc == -ENOENT)) + switch (rc) { + case 0: + /* + * The server may allow us to open things like + * FIFOs, but the client isn't set up to deal + * with that. If it's not a regular file, just + * close it and proceed as if it were a normal + * lookup. + */ + if (newInode && !S_ISREG(newInode->i_mode)) { + CIFSSMBClose(xid, pTcon, fileHandle); + break; + } + case -ENOENT: posix_open = true; - else if ((rc == -EINVAL) || (rc != -EOPNOTSUPP)) + case -EOPNOTSUPP: + break; + default: pTcon->broken_posix_open = true; + } } if (!posix_open) rc = cifs_get_inode_info_unix(&newInode, full_path,