Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1423597pxb; Thu, 4 Mar 2021 10:53:18 -0800 (PST) X-Google-Smtp-Source: ABdhPJzO/rC/qDlGEIjYUxGwYtVus7k2VK+pjeVN96y+Q/BYdeoYZ/dVqLO5lO/vyilvD3Sayw0L X-Received: by 2002:a17:906:5043:: with SMTP id e3mr5884187ejk.260.1614883998231; Thu, 04 Mar 2021 10:53:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614883998; cv=none; d=google.com; s=arc-20160816; b=r9WmodINQo4KH9X0BUTsWCGzd2xNf+Y6+ebVxPvI/Ga5OBqgYdFCoeHfEGj3D7v7yU vYsjZ1f1xNyxsyU6lJj2r+2G3n/wSHxHgbUjG7ch5thQG4+F0qMqdqX3GcxJkxf2BZDg qLWHmrrhX+1yXfb6F5ehI6AR/S9rjGCechpu8/gwJrrEMPVA4e8mZRNyGQ24fBmnuVse XBWidiT92yGXK+bWyW/zlQnzBerMw6wqzfO4gdCR69iYtgUhziGRSP3wXjLUgymptbsu egS1Nv6jB4ykFsVNo8DEcbuFAhS8ei7mdJIF3GEAAvgLtx0vZkMQX+hvb8oHgMK8Nutz Q9+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=tLQytJ9YJwiG2ADVzffVbb4x1Tv02ibhHLBj+HRS+o0=; b=e+yIQRkD7g+ACzQb6APpUAAUOlAPibuSDDsp/PgHKlvsXh/A2Hj1VLPKXfTNLEXN3L Wsc7fkA6ozAZxUcmDCvP1hoIKZzGrRrUqI0B1prLcuqzcLVTINKqQaGhfMlUy4i7EJuz +3kYjA0pgPm/AdH9a6iKMNTCLprSjxhCPBs61BF/CWj124IwT0WdRrTGNXZ8CQEYTJIB 15/9FTvHHH+LnXEUXb9EANyBIIVdgaIZ+WXmuG/WhKRSjXoy+d92WZFmPZ84Qbgcuae2 Zf0U9q7A81nS/VVgcjfr1c6TDakT5iKMYHeSamJrDQY0e3xa6zn+mQY2V6a1AlrPwVqS wTag== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=TFRhTk+0; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l19si218382edq.269.2021.03.04.10.52.54; Thu, 04 Mar 2021 10:53:18 -0800 (PST) Received-SPF: pass (google.com: domain of linux-ext4-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=@kernel.org header.s=k20201202 header.b=TFRhTk+0; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235987AbhCDR1Q (ORCPT + 99 others); Thu, 4 Mar 2021 12:27:16 -0500 Received: from mail.kernel.org ([198.145.29.99]:40324 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239347AbhCDR1M (ORCPT ); Thu, 4 Mar 2021 12:27:12 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id E386664E89; Thu, 4 Mar 2021 17:26:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1614878792; bh=HB4loAXLWA5MoyQDvfOGFQeSomA30bqcWhsrZ2wxtsw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=TFRhTk+0/ppdWpGnyHUxo6Gb/F0UjQUMOROnNxn+GSprEm5X8oX5gmpzN6xRwA9J9 KVwwRFZvXZ3gY1fFfRNdjgOdjDgZbAReN2aHjgNZ2mEDV+JQayw7cdCfPvK623by0N w7jjIoMN/hKzcGwh+YIa3JNYvksroW4Z9vMFNluOX5p/aCIdRc0MNl73I6jBj1uByJ Le9C9eepeV831JgDxJuoMXfI7DbRx8N9auvR49Zc6+CQAw+0saca14lm6DBBvYS4Ir WxytlnNqmujBaSs6vdBwbGw6w+XHLD4hR0zEnynHOgXs3eBHX0TbHHxNJTNfwlo7m2 PekzeBi/fDf0g== Date: Thu, 4 Mar 2021 09:26:31 -0800 From: "Darrick J. Wong" To: Ritesh Harjani Cc: linux-xfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, anju@linux.vnet.ibm.com Subject: Re: [PATCH] iomap: Fix negative assignment to unsigned sis->pages in iomap_swapfile_activate Message-ID: <20210304172631.GD7267@magnolia> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Thu, Mar 04, 2021 at 11:51:26AM +0530, Ritesh Harjani wrote: > In case if isi.nr_pages is 0, we are making sis->pages (which is > unsigned int) a huge value in iomap_swapfile_activate() by assigning -1. > This could cause a kernel crash in kernel v4.18 (with below signature). > Or could lead to unknown issues on latest kernel if the fake big swap gets > used. > > Fix this issue by returning -EINVAL in case of nr_pages is 0, since it > is anyway a invalid swapfile. Looks like this issue will be hit when > we have pagesize < blocksize type of configuration. > > I was able to hit the issue in case of a tiny swap file with below > test script. > https://raw.githubusercontent.com/riteshharjani/LinuxStudy/master/scripts/swap-issue.sh Can you turn this into a dangerous-group fstest, please? > kernel crash analysis on v4.18 > ============================== > On v4.18 kernel, it causes a kernel panic, since sis->pages becomes > a huge value and isi.nr_extents is 0. When 0 is returned it is > considered as a swapfile over NFS and SWP_FILE is set (sis->flags |= SWP_FILE). > Then when swapoff was getting called it was calling a_ops->swap_deactivate() > if (sis->flags & SWP_FILE) is true. Since a_ops->swap_deactivate() is > NULL in case of XFS, it causes below panic. Does the same reasoning apply to upstream? > Panic signature on v4.18 kernel: > ======================================= > root@qemu:/home/qemu# [ 8291.723351] XFS (loop2): Unmounting Filesystem > [ 8292.123104] XFS (loop2): Mounting V5 Filesystem > [ 8292.132451] XFS (loop2): Ending clean mount > [ 8292.263362] Adding 4294967232k swap on /mnt1/test/swapfile. Priority:-2 extents:1 across:274877906880k > [ 8292.277834] Unable to handle kernel paging request for instruction fetch > [ 8292.278677] Faulting instruction address: 0x00000000 > cpu 0x19: Vector: 400 (Instruction Access) at [c0000009dd5b7ad0] > pc: 0000000000000000 > lr: c0000000003eb9dc: destroy_swap_extents+0xfc/0x120 > sp: c0000009dd5b7d50 > msr: 8000000040009033 > current = 0xc0000009b6710080 > paca = 0xc00000003ffcb280 irqmask: 0x03 irq_happened: 0x01 > pid = 5604, comm = swapoff > Linux version 4.18.0 (riteshh@xxxxxxx) (gcc version 8.4.0 (Ubuntu 8.4.0-1ubuntu1~18.04)) #57 SMP Wed Mar 3 01:33:04 CST 2021 > enter ? for help > [link register ] c0000000003eb9dc destroy_swap_extents+0xfc/0x120 > [c0000009dd5b7d50] c0000000025a7058 proc_poll_event+0x0/0x4 (unreliable) > [c0000009dd5b7da0] c0000000003f0498 sys_swapoff+0x3f8/0x910 > [c0000009dd5b7e30] c00000000000bbe4 system_call+0x5c/0x70 > --- Exception: c01 (System Call) at 00007ffff7d208d8 > > Signed-off-by: Ritesh Harjani > --- > fs/iomap/swapfile.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/fs/iomap/swapfile.c b/fs/iomap/swapfile.c > index a648dbf6991e..67953678c99f 100644 > --- a/fs/iomap/swapfile.c > +++ b/fs/iomap/swapfile.c > @@ -170,6 +170,15 @@ int iomap_swapfile_activate(struct swap_info_struct *sis, > return ret; > } > > + /* > + * In case if nr_pages is 0 then we better return -EINVAL > + * since it is anyway an empty swapfile. > + */ > + if (isi.nr_pages == 0) { > + pr_warn("swapon: Empty swap-file\n"); The swapfile might not be empty, it's just that we couldn't find even a single page's worth of contiguous space in the whole file. I would suggest: /* * If this swapfile doesn't contain even a single page-aligned * contiguous range of blocks, reject this useless swapfile to * prevent confusion later on. */ if (isi.nr_pages == 0) { pr_warn("swapon: Cannot find a single usable page in file.\n"); return -EINVAL; } --D > + return -EINVAL; > + } > + > *pagespan = 1 + isi.highest_ppage - isi.lowest_ppage; > sis->max = isi.nr_pages; > sis->pages = isi.nr_pages - 1; > -- > 2.26.2 >