Jiri Slaby <jslaby@xxxxxxx> writes: > From: Theodore Ts'o <tytso@xxxxxxx> > > commit 0e9a9a1ad619e7e987815d20262d36a2f95717ca upstream. The 3.5 kernel was also missing this commit. I'm queuing it for the next release. Thanks! Cheers, -- Luis > > When trying to mount a file system which does not contain a journal, > but which does have a orphan list containing an inode which needs to > be truncated, the mount call with hang forever in > ext4_orphan_cleanup() because ext4_orphan_del() will return > immediately without removing the inode from the orphan list, leading > to an uninterruptible loop in kernel code which will busy out one of > the CPU's on the system. > > This can be trivially reproduced by trying to mount the file system > found in tests/f_orphan_extents_inode/image.gz from the e2fsprogs > source tree. If a malicious user were to put this on a USB stick, and > mount it on a Linux desktop which has automatic mounts enabled, this > could be considered a potential denial of service attack. (Not a big > deal in practice, but professional paranoids worry about such things, > and have even been known to allocate CVE numbers for such problems.) > > -js: This is a fix for CVE-2013-2015. > > Signed-off-by: "Theodore Ts'o" <tytso@xxxxxxx> > Reviewed-by: Zheng Liu <wenqing.lz@xxxxxxxxxx> > Cc: stable@xxxxxxxxxxxxxxx > Acked-by: Jan Kara <jack@xxxxxxx> > Signed-off-by: Jiri Slaby <jslaby@xxxxxxx> > --- > fs/ext4/namei.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c > index 8d3716f..595d087 100644 > --- a/fs/ext4/namei.c > +++ b/fs/ext4/namei.c > @@ -2059,7 +2059,8 @@ int ext4_orphan_del(handle_t *handle, struct inode *inode) > int err = 0; > > /* ext4_handle_valid() assumes a valid handle_t pointer */ > - if (handle && !ext4_handle_valid(handle)) > + if (handle && !ext4_handle_valid(handle) && > + !(EXT4_SB(inode->i_sb)->s_mount_state & EXT4_ORPHAN_FS)) > return 0; > > mutex_lock(&EXT4_SB(inode->i_sb)->s_orphan_lock); -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html