lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 20 Jun 2014 19:38:19 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Nick Krause <xerofoify@...il.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Dan Carpenter <dan.carpenter@...cle.com>,
	viro@...iv.linux.org.uk, fabf@...net.be,
	kirill.shutemov@...ux.intel.com, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Check for Null return of function of affs_bread in
 function affs_truncate

On Fri, 20 Jun 2014 22:25:47 -0400 Nick Krause <xerofoify@...il.com> wrote:

> If you have any ideas about what is better
> please let me known.

I think the proposed patch was not a good one - it will cause truncate
to silently return, probably leaving the fs in an inconsistent state. 
Neither the user nor the running application know this happened so they
will just keep on modifying the filesystem, possibly mangling it
further.

The code as it stands at present is better - if bread() fails we'll get
a nice solid oops and the current app will be terminated (at least). 
As we're in truncate it's quite possible that the entire fs will get
wedged up due to now-permanently-held i_mutex, which is even better.


As for the best fix, umm, hard.  We're pretty screwed if we cannot read
that block at this code site.  Perhaps emit loud printks, forcibly turn
the fs read-only then return -EIO/-ENOMEM/etc from the truncate.  Such
a change would require runtime testing, with some form of developer fault
injection.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ