linux-ext4 - [Bug 200931] use-after-free in ext4_put

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:   Mon, 27 Aug 2018 02:23:59 +0000
From:   bugzilla-daemon@...zilla.kernel.org
To:     linux-ext4@...nel.org
Subject: [Bug 200931] use-after-free in ext4_put_super()

https://bugzilla.kernel.org/show_bug.cgi?id=200931

--- Comment #5 from Theodore Tso (tytso@....edu) ---
The root cause of the problem is as follows.

Setup: the file system has an inode, inode #16, that has a i_nlink of 1. 
However, there are two directory entries (with weird names for no good reason
but it makes life more difficult for the bug hunter), which I will call file A
and file B that both are hard links to inode #16.

1)  Call chmod(File A, 3072);   This brings Filename A into the dcache

2)  Unlink File B.  This drops the i_nlink to zero; since this means that
there should be no remaining hardlinks to the file --- but i_count > 0, since
we have a dcache entry for Filename A --- inode #16 is put on the orphan inode
list.

3)  Create a new file, call it File C.

4)  Rename File C on top of File A.   This causes a warning to get issued since
there is an attempt to drop i_nlink to a negative value.   That gets ignored so
i_nlink stays at 0.  But now i_count gets dropped down to 0, so the inode gets
deleted and freed.  But, the inode structure is still on the orphan inode list!

5)  At unmount time, the fact that we still have an inode on the orphan inode
list causes a warning to be printed, but it also causes the access to the freed
data structure.

The fix is to enforce a check that if new.inode exists, its i_nlink must be >
0.    If it is 0, then something is badly wrong, and we should mark the file
system as corrupted and return EFSCORRUPTED.

The problem is obvious once we have the simplified poc.   With the original
poc, instead of 4 operations, there are 100 operations, most of which are
complete red herrings.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.