NetBSD Problem Report #56325

From www@netbsd.org  Thu Jul 22 21:07:42 2021
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 7BEC51A921F
	for <gnats-bugs@gnats.NetBSD.org>; Thu, 22 Jul 2021 21:07:42 +0000 (UTC)
Message-Id: <20210722210740.D12331A9241@mollari.NetBSD.org>
Date: Thu, 22 Jul 2021 21:07:40 +0000 (UTC)
From: vezhlys@gmail.com
Reply-To: vezhlys@gmail.com
To: gnats-bugs@NetBSD.org
Subject: chfs panics on file truncation reproducible using dd
X-Send-Pr-Version: www-1.0

>Number:         56325
>Category:       kern
>Synopsis:       chfs panics on file truncation reproducible using dd
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jul 22 21:10:01 +0000 2021
>Originator:     Andrius V
>Release:        NetBSD 9.99.86
>Organization:
>Environment:
NetBSD  9.99.86 NetBSD 9.99.86 (GENERIC) #21: Wed Jul 21 17:49:17 EEST 2021  andriusv@jarossd:/home/andriusv/workspace/netbsd-obj/sys/arch/amd64/compile/GENERIC amd64
>Description:
One more (not the last one) bug in chfs file system is in file truncation, always reproducible by writing file using as an example "dd if=/dev/zero of=some.img bs=1024 seek=20480" and then rewriting it into the same filename with "quite" (I guess more than block size) smaller size (e.g. seek=10240). The problem lies in sys/ufs/chfs/chfs_subr.c#235 ubc_zerorange(&vp->v_uobj, size, ip->size - size, UBC_VNODE_FLAGS(vp)); call, which eventually panics at memset in sys/uvm/uvm_bio.c#828. I believe issue is caused by wrong value sent to this function in (ip->size - size) calculation, since "ip->size" hold the full old bigger file size and "size" is the full new smaller file size. Looking at other fs implementations, it seems it should zero out only the last unfinished block past the new EOF instead.


fatal page fault in supervisor mode
trap type 6 code 0x2 rip 0xffffffff80ec19cc cs 0x8 rflags 0x10216 cr2 0xffffd480a7150000 ilevel 0 rsp 0xffffd480b7244cd8
curlwp 0xffff826da6f0db00 pid 555.555 lowest kstack 0xffffd480b72402c0
panic: trap
cpu1: Begin traceback...
vpanic() at netbsd:vpanic+0x156
device_printf() at netbsd:device_printf
startlwp() at netbsd:startlwp
alltraps() at netbsd:alltraps+0xc3
chfs_chsize() at chfs:chfs_chsize+0x112
chfs_setattr() at chfs:chfs_setattr+0xd8
VOP_SETATTR() at netbsd:VOP_SETATTR+0x3d
sys_ftruncate() at netbsd:sys_ftruncate+0xd4
syscall() at netbsd:syscall+0x196
 --- syscall (number 201) ---
netbsd:syscall+0x196:
cpu1: End traceback...
>How-To-Repeat:
modload nandemulator
mount -t chfs /dev/flash0 /mnt
dd if=/dev/zero of=some.img bs=1024 seek=20480
dd if=/dev/zero of=some.img bs=1024 seek=10240
(should crash with above)


>Fix:
Don't have a patch, but I believe, the of "ip->size" should be replaced with calculated value of size plus (up to) 1 block size.

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.46 2020/01/03 16:35:01 leot Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2020 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.