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  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, 25 Feb 2022 21:23:37 -0500
From:   "Theodore Ts'o" <>
To:     Ye Bin <>
Subject: Re: [PATCH -next v2] ext4:fix file system corrupted when rmdir non
 empty directory with IO error

On Fri, Feb 11, 2022 at 05:35:27PM +0800, Ye Bin wrote:
> Now if read directory block failed, 'ext4_empty_dir' will return true, assume
> directory is empty. Obviously, it will lead to above issue.
> To solve this issue, if read directory block failed 'ext4_empty_dir' just assume
> directory isn't empty. To avoid making things worse when file system is already
> corrupted, 'ext4_empty_dir' also assume directory isn't empty.
> To distinguish the error type, return the exact error code to the caller.

Does the same issue exist for f2fs and ubifs?  We could solve the
specific bug much more simply by having ext4_empty_dir() return FALSE
if we aren't able to read the directory block.  Yes, it means that we
don't return as specific an error code in the case of an I/O error ---
although I believe we do syslog a warning --- but it makes for a much
simpler patch that doesn't requiring getting acked-by's from the
fscrypt, f2fs and ubifs folks.

							- Ted

Powered by blists - more mailing lists