Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp3688152pxb; Mon, 24 Jan 2022 15:24:07 -0800 (PST) X-Google-Smtp-Source: ABdhPJw41IcRy780FZOegFGgiyUdwKnjliHsHyJbzL5KYDNg3zJi097ZgZxGjOVhPkWbeDhzDcTc X-Received: by 2002:a63:2a11:: with SMTP id q17mr13187880pgq.394.1643066647502; Mon, 24 Jan 2022 15:24:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643066647; cv=none; d=google.com; s=arc-20160816; b=klbWgNee+5sWw2iYasRWyBVf3+h9hEb15fGCe5QFGIdVmbD6vv8LJ2H8BrD8UTRu5T 5/4S4TXY3iCbUPWMNwTuUsHdPvoVlh8cX6Y97AL8j6Vj/jPkyAbRj2cRWxSE08KEQYN2 OptsEn87O6IOC+m0DJQlYYWcYG8yRoqFy1nedRFiygMUmcCDz4WeQEWspo/4HwQtOaP0 312LI6Sm3BVScBAYpA1EQaVpfp5yskONay52FWRVemRCuwJvHfpgBNpSzDGt1AyYpsAD vYkIvWC54ETSnDnE7uleIJr/lUaJDT/gVAZ3uDtRE2+biaYzBaVr4lk2DSWGeglNtYUR 7eLw== 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=CNz8R8HkXR5AaAgintc4pABJqIBNq8+7nSciKr7ul5w=; b=hbeUtCyoxlEZDr5/yftli+EnumG7YWQS/WGHryHBWTB8fdCXzdsHRjc1fPFk3NgQKD 8Xl2C3HkuE+2bgce9HmiwGr+tiZBy6/s0aaAWXchq4/sKYR3UrTO9HgvSJV7WkvVa3ys 1qw9oeP7u76JFf9k8UDDuYesizJXJbIm7cqC8h0dtDLSVAnLh9V18Qa672+iZgUqVfj0 YX9Egofv3Yyf18sNban0H3S+dJXpYQM89YruxVQIDE56KUmbFzslnS0NSTeF1Rey1jKi R4+kYR4LadKZwaFyqNYaYoY7wC+rG9rqBxa4HJfw/Dtc7n5xQ+S/fP0VZy9HunBylTzG jrgg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=UmJbyc5V; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h9si14907534pgg.455.2022.01.24.15.23.45; Mon, 24 Jan 2022 15:24:07 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=UmJbyc5V; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.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: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1385890AbiAXXTB (ORCPT + 99 others); Mon, 24 Jan 2022 18:19:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37662 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1584689AbiAXWVd (ORCPT ); Mon, 24 Jan 2022 17:21:33 -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 48013C041882; Mon, 24 Jan 2022 12:52:54 -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 04579B80CCF; Mon, 24 Jan 2022 20:52:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2E942C36AE3; Mon, 24 Jan 2022 20:52:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643057571; bh=uDUAb+qZBHXld3qkmkZnFDhDfgMIF+C1eIkgRfrPvD4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UmJbyc5VqwfYgT8jI0xcQRz58kmNnPh4O44QkvDnf+y2Zv3/jfEgPzeFAS2JpQZcI cNe1CplXU58HRALIM+SSju3j9OPWnJjLuqROz6WPNdO2HtTi8OPSGAB5bqeHZJe9BQ bAXbWyn5pDNLm9VCrG4s0GgicMH6q3nC6QGPBo+c= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Wenqing Liu , Chao Yu , Jaegeuk Kim Subject: [PATCH 5.16 0010/1039] f2fs: fix to do sanity check on inode type during garbage collection Date: Mon, 24 Jan 2022 19:29:59 +0100 Message-Id: <20220124184125.486229792@linuxfoundation.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220124184125.121143506@linuxfoundation.org> References: <20220124184125.121143506@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Chao Yu commit 9056d6489f5a41cfbb67f719d2c0ce61ead72d9f upstream. As report by Wenqing Liu in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215231 - Overview kernel NULL pointer dereference triggered in folio_mark_dirty() when mount and operate on a crafted f2fs image - Reproduce tested on kernel 5.16-rc3, 5.15.X under root 1. mkdir mnt 2. mount -t f2fs tmp1.img mnt 3. touch tmp 4. cp tmp mnt F2FS-fs (loop0): sanity_check_inode: inode (ino=49) extent info [5942, 4294180864, 4] is incorrect, run fsck to fix F2FS-fs (loop0): f2fs_check_nid_range: out-of-range nid=31340049, run fsck to fix. BUG: kernel NULL pointer dereference, address: 0000000000000000 folio_mark_dirty+0x33/0x50 move_data_page+0x2dd/0x460 [f2fs] do_garbage_collect+0xc18/0x16a0 [f2fs] f2fs_gc+0x1d3/0xd90 [f2fs] f2fs_balance_fs+0x13a/0x570 [f2fs] f2fs_create+0x285/0x840 [f2fs] path_openat+0xe6d/0x1040 do_filp_open+0xc5/0x140 do_sys_openat2+0x23a/0x310 do_sys_open+0x57/0x80 The root cause is for special file: e.g. character, block, fifo or socket file, f2fs doesn't assign address space operations pointer array for mapping->a_ops field, so, in a fuzzed image, SSA table indicates a data block belong to special file, when f2fs tries to migrate that block, it causes NULL pointer access once move_data_page() calls a_ops->set_dirty_page(). Cc: stable@vger.kernel.org Reported-by: Wenqing Liu Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman --- fs/f2fs/gc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/fs/f2fs/gc.c +++ b/fs/f2fs/gc.c @@ -1457,7 +1457,8 @@ next_step: if (phase == 3) { inode = f2fs_iget(sb, dni.ino); - if (IS_ERR(inode) || is_bad_inode(inode)) + if (IS_ERR(inode) || is_bad_inode(inode) || + special_file(inode->i_mode)) continue; if (!down_write_trylock(