From patchwork Fri Aug 2 17:11:28 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Connor Kuehl X-Patchwork-Id: 1141319 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]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 460Ybv0zgHz9s3Z; Sat, 3 Aug 2019 03:11:38 +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 1htb5Z-0003nm-RG; Fri, 02 Aug 2019 17:11:33 +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 1htb5Y-0003ne-DH for kernel-team@lists.ubuntu.com; Fri, 02 Aug 2019 17:11:32 +0000 Received: from mail-pg1-f199.google.com ([209.85.215.199]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1htb5X-00018i-U0 for kernel-team@lists.ubuntu.com; Fri, 02 Aug 2019 17:11:32 +0000 Received: by mail-pg1-f199.google.com with SMTP id e33so5808775pgm.20 for ; Fri, 02 Aug 2019 10:11:31 -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:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=rPDujnLOpBtUx4AIjiBhwD2JS98dv1vlJWxODn34RIw=; b=KI8IN6iiTN8ZRpjvgpV8KCCBrB5Nvxn184E1rRGymDaA7x/gA7+pEgeUdm3Xh1X9Cd X/Kh0kFZ3uAkOMsHCNOLPtWrIejSKeYmK1bcECMohQ2hUqT+I9u5HHWw/81zXjEpVPQC WFBrPhDUxZIZhbQ8pez65kO8SNqmYuKXMgguZ8LHvc+obqxYIZWvoJ49NpeKh4eZgLlw HCzB9aUqTHYae+BMhnga6JuVyAdn1/psBqjGQEAPkZz2u7txIFx2g66Chh3f1QTbCzl3 7T4keTh2eZb1Rw5pFMcF7jQsHVQFnjKDRCcHuxmKlDpaF5PV2WomWEI+lnks/7iRScba 2Zhw== X-Gm-Message-State: APjAAAW8J/tDgHkBVh04/TriPt5fzSUM23VqwelGaBHp++sYsjt9GNqh IDod9Ut7loti89EwJuHWuYf06Ko2eBxGvtQQL3TgZ8ER5+NDbVHFvHbQf4aAT9bsihco+Sxb6iR l2PTGF99XcaeKkJwMaU7khlckHU+jhjQbxr0UBkcNGw== X-Received: by 2002:a17:902:846:: with SMTP id 64mr132440269plk.265.1564765890359; Fri, 02 Aug 2019 10:11:30 -0700 (PDT) X-Google-Smtp-Source: APXvYqwj7MO9rauBRJLjJ+Fdfg9B0Af4p3lRgywytCaE3dNFceWKsMi61Z/j0SkSvkhmqmtHIAMsrQ== X-Received: by 2002:a17:902:846:: with SMTP id 64mr132440256plk.265.1564765890227; Fri, 02 Aug 2019 10:11:30 -0700 (PDT) Received: from localhost.localdomain (c-71-63-131-226.hsd1.or.comcast.net. [71.63.131.226]) by smtp.gmail.com with ESMTPSA id f12sm67784577pgo.85.2019.08.02.10.11.28 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Fri, 02 Aug 2019 10:11:29 -0700 (PDT) From: Connor Kuehl To: kernel-team@lists.ubuntu.com Subject: [SRU][Xenial][CVE-2018-20856][PATCH] block: blk_init_allocated_queue() set q->fq as NULL in the fail case Date: Fri, 2 Aug 2019 10:11:28 -0700 Message-Id: <20190802171128.10484-1-connor.kuehl@canonical.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 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: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: xiao jin CVE-2018-20856 We find the memory use-after-free issue in __blk_drain_queue() on the kernel 4.14. After read the latest kernel 4.18-rc6 we think it has the same problem. Memory is allocated for q->fq in the blk_init_allocated_queue(). If the elevator init function called with error return, it will run into the fail case to free the q->fq. Then the __blk_drain_queue() uses the same memory after the free of the q->fq, it will lead to the unpredictable event. The patch is to set q->fq as NULL in the fail case of blk_init_allocated_queue(). Fixes: commit 7c94e1c157a2 ("block: introduce blk_flush_queue to drive flush machinery") Cc: Reviewed-by: Ming Lei Reviewed-by: Bart Van Assche Signed-off-by: xiao jin Signed-off-by: Jens Axboe (backported from commit 54648cf1ec2d7f4b6a71767799c45676a138ca24) [ Connor Kuehl: had to place the line from the patch in manually since the patch context disagreed with what the routine looks like now (different label, different return statement). Barely more involved than an offset adjustment. ] Signed-off-by: Connor Kuehl Acked-by: Tyler Hicks --- block/blk-core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/block/blk-core.c b/block/blk-core.c index f83b9c2b6a14..a3e1f4fcb2e5 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -861,6 +861,7 @@ blk_init_allocated_queue(struct request_queue *q, request_fn_proc *rfn, fail: blk_free_flush_queue(q->fq); + q->fq = NULL; return NULL; } EXPORT_SYMBOL(blk_init_allocated_queue);