linux-ext4 - [Bug 199183] Invalid pointer dereference in ext4_xattr_inode_hash when mounting and later operating on a crafted image

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: <bug-199183-13602-LByRYkAn8o@https.bugzilla.kernel.org/>
Date:   Mon, 26 Mar 2018 04:08:16 +0000
From:   bugzilla-daemon@...zilla.kernel.org
To:     linux-ext4@...nel.org
Subject: [Bug 199183] Invalid pointer dereference in ext4_xattr_inode_hash
 when mounting and later operating on a crafted image

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

--- Comment #4 from Theodore Tso (tytso@....edu) ---
OK, I was able to replicate this on 4.15, but it's not replicating on 4.16-rc1.
 However, the underlying issue was NOT that inode->i_sb is NULL, but rather
that s_chksum_driver (found in EXT4_SBI(inode->i_sb)->s_chksum_driver) was
NULL.

I'm not sure why we're not ending up calling ext4_chksum() in 4.16-rc1, but the
xattr code can try to calculate a crc32c, and so we should just initialize the
s_chksum_driver() unconditionally.  It will make things simpler, and avoid a
bunch of problems.

In addition, the file system should have never been allowed to have been
mounted in the first place, since one of the block allocation bitmaps
overlapped with the superblock, and this means that as blocks got allocated,
the superblock was getting corrupted.

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