From patchwork Fri Apr 20 12:50:16 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kleber Sacilotto de Souza X-Patchwork-Id: 901894 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=canonical.com Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) by ozlabs.org (Postfix) with ESMTP id 40SG136Cpqz9s7Q; Fri, 20 Apr 2018 22:50:31 +1000 (AEST) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1f9VUh-0003gp-CA; Fri, 20 Apr 2018 12:50:27 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by huckleberry.canonical.com with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.86_2) (envelope-from ) id 1f9VUe-0003fZ-1P for kernel-team@lists.ubuntu.com; Fri, 20 Apr 2018 12:50:24 +0000 Received: from mail-wr0-f198.google.com ([209.85.128.198]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1f9VUd-0000xO-QH for kernel-team@lists.ubuntu.com; Fri, 20 Apr 2018 12:50:23 +0000 Received: by mail-wr0-f198.google.com with SMTP id 31-v6so8746965wrr.2 for ; Fri, 20 Apr 2018 05:50:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references; bh=KWsrqAZ8HJxTyEekXLq7As3HmjWYApAV8jBwx/XckOw=; b=lVJ2BgBpjfn7EzGdoAMtWeZoITrGeiBciEOZph6TZUaDUzgXLOiVpnaY6hGYkfMxPG 3qI2OgIoD6QDIiImIJjPh1y0DV4WEhKx7Zma/574eJDrptG9kb6JoGiBZyEypoU8crTN /tYtIwNoKUXVfLHyhAj8srrD27zt8w9/1gfmbGHEYUebm5WwensNl6JMCwyj/jKvG6dM iNoakt5RWZvt/nuCM6JTueEz7lEGxTIl9G+NRi8B/AM+cE+yuMj/8zJ5wh3n+ktwfSjE CSGbbB2sgNrn3t7PfORq9jzKkUpTT1+BKftBq/fX8+6DM+f306YNsRoR0noR6SvM2Kv/ BG/w== X-Gm-Message-State: ALQs6tAliwlCWtxQP28+wyyWsdFXGR2iDV+H6EyVm906Hhhd8KdhHMFa 1Ie4kUvsSA7UP+d0s/UC2Ncx+C04uct57xMVUOE1dgfLxLmnoI9WlOPCOStXeBgM/dZ2e0mgJeS JU7cIg6zhnHDwKZ40GYhSNWoe4JKRpcdI7mmJjPR4/w== X-Received: by 2002:adf:cd8e:: with SMTP id q14-v6mr489548wrj.277.1524228623256; Fri, 20 Apr 2018 05:50:23 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+A7NoaZ/oBasvSYDYKEXvNibHzb/W2/V+EvAkGOpf55LoCcoLSymp97KjQcDU8ej86wenYuQ== X-Received: by 2002:adf:cd8e:: with SMTP id q14-v6mr489537wrj.277.1524228623086; Fri, 20 Apr 2018 05:50:23 -0700 (PDT) Received: from localhost ([212.121.131.210]) by smtp.gmail.com with ESMTPSA id 60-v6sm5056797wrj.62.2018.04.20.05.50.22 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 20 Apr 2018 05:50:22 -0700 (PDT) From: Kleber Sacilotto de Souza To: kernel-team@lists.ubuntu.com Subject: [SRU][Artful][PATCH 1/1] mm/madvise.c: fix madvise() infinite loop under special circumstances Date: Fri, 20 Apr 2018 14:50:16 +0200 Message-Id: <20180420125016.10300-3-kleber.souza@canonical.com> X-Mailer: git-send-email 2.14.1 In-Reply-To: <20180420125016.10300-1-kleber.souza@canonical.com> References: <20180420125016.10300-1-kleber.souza@canonical.com> X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: chenjie CVE-2017-18208 MADVISE_WILLNEED has always been a noop for DAX (formerly XIP) mappings. Unfortunately madvise_willneed() doesn't communicate this information properly to the generic madvise syscall implementation. The calling convention is quite subtle there. madvise_vma() is supposed to either return an error or update &prev otherwise the main loop will never advance to the next vma and it will keep looping for ever without a way to get out of the kernel. It seems this has been broken since introduction. Nobody has noticed because nobody seems to be using MADVISE_WILLNEED on these DAX mappings. [mhocko@suse.com: rewrite changelog] Link: http://lkml.kernel.org/r/20171127115318.911-1-guoxuenan@huawei.com Fixes: fe77ba6f4f97 ("[PATCH] xip: madvice/fadvice: execute in place") Signed-off-by: chenjie Signed-off-by: guoxuenan Acked-by: Michal Hocko Cc: Minchan Kim Cc: zhangyi (F) Cc: Miao Xie Cc: Mike Rapoport Cc: Shaohua Li Cc: Andrea Arcangeli Cc: Mel Gorman Cc: Kirill A. Shutemov Cc: David Rientjes Cc: Anshuman Khandual Cc: Rik van Riel Cc: Carsten Otte Cc: Dan Williams Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds (cherry picked from commit 6ea8d958a2c95a1d514015d4e29ba21a8c0a1a91) Signed-off-by: Kleber Sacilotto de Souza Acked-by: Colin Ian King --- mm/madvise.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/mm/madvise.c b/mm/madvise.c index 4edca1d86339..d968b9fc0a7e 100644 --- a/mm/madvise.c +++ b/mm/madvise.c @@ -264,15 +264,14 @@ static long madvise_willneed(struct vm_area_struct *vma, { struct file *file = vma->vm_file; + *prev = vma; #ifdef CONFIG_SWAP if (!file) { - *prev = vma; force_swapin_readahead(vma, start, end); return 0; } if (shmem_mapping(file->f_mapping)) { - *prev = vma; force_shm_swapin_readahead(vma, start, end, file->f_mapping); return 0; @@ -287,7 +286,6 @@ static long madvise_willneed(struct vm_area_struct *vma, return 0; } - *prev = vma; start = ((start - vma->vm_start) >> PAGE_SHIFT) + vma->vm_pgoff; if (end > vma->vm_end) end = vma->vm_end;