From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from www262.sakura.ne.jp ([202.181.97.72]:35846 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754498AbeFMWJt (ORCPT ); Wed, 13 Jun 2018 18:09:49 -0400 Subject: Re: [PATCH] bfs: add sanity check at bfs_fill_super(). To: Tigran Aivazian Cc: Andrew Morton , linux-fsdevel@vger.kernel.org, syzbot , syzkaller-bugs References: <1525862104-3407-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> <20180509160658.c37bef542a8ee5245a13917b@linux-foundation.org> <201805092346.w49NkINl045657@www262.sakura.ne.jp> <20180509165321.3b2b1313fde0f007c1a5a015@linux-foundation.org> <9ef86114-02d6-b243-203d-fbbdab95a6fa@I-love.SAKURA.ne.jp> From: Tetsuo Handa Message-ID: Date: Thu, 14 Jun 2018 07:09:31 +0900 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 2018/06/13 22:49, Tigran Aivazian wrote: > Having read the discussion carefully, I personally prefer to ignore > the fix as invalid, because mounting a filesystem image is a > privileged operation and if attempting to mount a corrupted image > causes a panic, that is no big deal, imho. While this report is triggered by a crafted filesystem image, I don't think that a legitimate but huge filesystem image crashes the system by hitting (size > KMALLOC_MAX_SIZE) path is nice. While filesystem should try to avoid such large allocation, there is no need to crash the system just because kmalloc() failed. e.g. http://lkml.kernel.org/r/927f24d4-b0c3-8192-5723-c314f38b4292@iogearbox.net