Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp1656594pxb; Wed, 9 Feb 2022 01:22:39 -0800 (PST) X-Google-Smtp-Source: ABdhPJzffREEcCJKRkBhxUJsZt3tcO5byRtnGOMQAf38oYIPlM3RArpYUOEB1Uhkd3NwnWeXH8/f X-Received: by 2002:a63:6985:: with SMTP id e127mr1150756pgc.567.1644398559327; Wed, 09 Feb 2022 01:22:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644398559; cv=none; d=google.com; s=arc-20160816; b=VRqljzopNXgnCAyJR2GBM0NJXcSheBoJhloXLu8xqzh79+CV28ZFuM0ssW+3RAte1A VrHJDKwZIcobddh6Vy6eu7hagid64tKC8StLW6Xy11oouye9L9qgu/vdxWuyYwHxIP6A eg0+A4KXeV56YKv22n9feyqhf3jTHUjvN7MPefP1QwOBT5cWFZ1NCuGtiHUWyL+50SED fwE0mNMDN244L3iD/YWvf0aQF7396qSqJWVDh/KTRhlJlAFViMBBLsw1TEJVdi/fuoAS dGMIJrv2ucuwS+xMiHCv/vxFK8WJysQfexmVyRxrVqDfZnJdtGUinNWM/GFekg4JVJcN BqEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=LjxDLivhTjG4A87G7rIG2zGzfLoDsr3JfCn2ExxR6M0=; b=VyZkEnpEvKmF3l9OuqmkiVO5nxM366WoxxN+E1r3u+hKUWvVr0nWcnwz0jCrhrt9pe 9Tos8xIWn/8YhAYTITNFtEcGr5/+FgqZxRwzkOCBCzo8+lftChi82x/lJsMPbFaqZwLk a4b3wIlOsgPglOOMMQgziGRH4yIOx8svdx7Sw1fz/zIK56dB7cws3LqtjhKjRHrrBtcY VZB7p5VAdN58q6TXyzEumXebo1azaKUvOGK/dP7SWAq/0yJk0iTnPNvkoofJoGdXRA64 SC5YgNvbiZytSaQurGY9kv8HOE1kGYYwr5V6CO+r00DWGtdcNgCXQv909mdIewdHeAfb mrHA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=R3Im7JHZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id g69si14471984pgc.241.2022.02.09.01.22.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Feb 2022 01:22:39 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=R3Im7JHZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 74F20E039216; Wed, 9 Feb 2022 00:57:00 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1382569AbiBGLTs (ORCPT + 99 others); Mon, 7 Feb 2022 06:19:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53060 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1376383AbiBGLPH (ORCPT ); Mon, 7 Feb 2022 06:15:07 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 11642C03FEC3; Mon, 7 Feb 2022 03:14:49 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id B5F86B811BC; Mon, 7 Feb 2022 11:14:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 04E04C004E1; Mon, 7 Feb 2022 11:14:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1644232485; bh=djhrL4rw+Ch721ysSBP7ZmkRuMo00a3GMzPeylgxBT4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=R3Im7JHZ/gsOhG2r/qXK4bo5zS2OLpncv/uDc3J5/gH/ZPyaNrC+WD1CquIV+9anY ypQAz+NVa4RT8fmLSefyz3J7FiZBhB+hJfKahws6GjaU+iaBFjn3K448wqb9RUA8eX LFSX6egsQzwQwe9UxbCdXNrGb/dJVWZ8b2s04USE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, butt3rflyh4ck , Christoph Hellwig , Jan Kara Subject: [PATCH 4.19 05/86] udf: Fix NULL ptr deref when converting from inline format Date: Mon, 7 Feb 2022 12:05:28 +0100 Message-Id: <20220207103757.733237983@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220207103757.550973048@linuxfoundation.org> References: <20220207103757.550973048@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Jan Kara commit 7fc3b7c2981bbd1047916ade327beccb90994eee upstream. udf_expand_file_adinicb() calls directly ->writepage to write data expanded into a page. This however misses to setup inode for writeback properly and so we can crash on inode->i_wb dereference when submitting page for IO like: BUG: kernel NULL pointer dereference, address: 0000000000000158 #PF: supervisor read access in kernel mode ... __folio_start_writeback+0x2ac/0x350 __block_write_full_page+0x37d/0x490 udf_expand_file_adinicb+0x255/0x400 [udf] udf_file_write_iter+0xbe/0x1b0 [udf] new_sync_write+0x125/0x1c0 vfs_write+0x28e/0x400 Fix the problem by marking the page dirty and going through the standard writeback path to write the page. Strictly speaking we would not even have to write the page but we want to catch e.g. ENOSPC errors early. Reported-by: butt3rflyh4ck CC: stable@vger.kernel.org Fixes: 52ebea749aae ("writeback: make backing_dev_info host cgroup-specific bdi_writebacks") Reviewed-by: Christoph Hellwig Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman --- fs/udf/inode.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) --- a/fs/udf/inode.c +++ b/fs/udf/inode.c @@ -251,10 +251,6 @@ int udf_expand_file_adinicb(struct inode char *kaddr; struct udf_inode_info *iinfo = UDF_I(inode); int err; - struct writeback_control udf_wbc = { - .sync_mode = WB_SYNC_NONE, - .nr_to_write = 1, - }; WARN_ON_ONCE(!inode_is_locked(inode)); if (!iinfo->i_lenAlloc) { @@ -298,8 +294,10 @@ int udf_expand_file_adinicb(struct inode iinfo->i_alloc_type = ICBTAG_FLAG_AD_LONG; /* from now on we have normal address_space methods */ inode->i_data.a_ops = &udf_aops; + set_page_dirty(page); + unlock_page(page); up_write(&iinfo->i_data_sem); - err = inode->i_data.a_ops->writepage(page, &udf_wbc); + err = filemap_fdatawrite(inode->i_mapping); if (err) { /* Restore everything back so that we don't lose data... */ lock_page(page);