linux-kernel - Re: [PATCH 2/2] Fix possible leakage of blocks in UDF

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]

Message-ID: <20070602140619.GA10303@cvg>
Date:	Sat, 2 Jun 2007 18:06:19 +0400
From:	Cyrill Gorcunov <gorcunov@...il.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Cyrill Gorcunov <gorcunov@...il.com>,
	Eric Sandeen <sandeen@...deen.net>, Jan Kara <jack@...e.cz>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] Fix possible leakage of blocks in UDF

[Andrew Morton - Sat, Jun 02, 2007 at 12:06:45AM -0700]
| On Sat, 2 Jun 2007 10:59:23 +0400 Cyrill Gorcunov <gorcunov@...il.com> wrote:
| 
| > [Andrew Morton - Fri, Jun 01, 2007 at 11:54:22PM -0700]
| > | On Sat, 2 Jun 2007 10:34:03 +0400 Cyrill Gorcunov <gorcunov@...il.com> wrote:
| > | 
| > | > | That patch is DOA, methinks.
| > | > | 
| > | > 
| > | > Andrew, what does it mean - "DOA"? Dead on arrival?
| > | 
| > | yes - I dropped it.
| > | 
| > 
| > But that could lead to rejection of my code-style-conversion patch...
| > Should I remake them?
| 
| Actually I've rebuilt those patches four times already.  People keep
| changing stuff.
| 
| > Actually Jan was right, the current state of UDF (without his patches)
| > could lead to lost blocks and his patch must be just fixed I think.
| 
| sure.
| 

Andrew, you know I've been trying to reproduce Eric's lockup case almost
two hour and still can't reach it. All manupulation I've done to UDF didn't
lead to lockup. Moreover, I've added debug print for UDF module and here is
the results (for single drop_inode call):

	[12063.897000] UDF: udf_drop_inode:105 --> udf_drop_inode --> inode->i_count: 0
	[12063.897000] UDF: udf_drop_inode:107 udf_drop_inode -> discard_prealloc
	[12063.897000] UDF: udf_discard_prealloc:136 udf_discard_prealloc
	[12063.897000] UDF: udf_truncate_tail_extent:84 udf_truncate_tail_extent
	[12063.897000] UDF: udf_truncate_extents:194 udf_truncate_extents -->
	[12063.897000] UDF: extent_trunc:38 --->
	[12063.897000] UDF: extent_trunc:54 call to udf_write_aext
	[12063.897000] UDF: udf_write_aext:1843 udf_write_aext
	[12063.897000] UDF: udf_write_aext:1846 dont has epos->bh
	[12063.897000] UDF: udf_write_aext:1866 ICBTAG_FLAG_AD_LONG
--->	[12063.897000] UDF: udf_write_aext:1893 ---> gotcha ---> call mark_inode_dirty
--->	[12063.897000] UDF: extent_trunc:59 --> gotcha --> call mark_inode_dirty
	[12063.897000] UDF: extent_trunc:68 <---
--->	[12063.897000] UDF: udf_truncate_extents:282 call mark_inode_dirty
	[12063.897000] UDF: udf_truncate_extents:330 udf_truncate_extents <--
	[12063.897000] UDF: udf_drop_inode:115 <-- udf_drop_inode <--

As you may see, mark_inode_dirty is called several time and no locking happened.
Maybe I should use some test utils?

		Cyrill

-
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/