linux-ext4 - [Bug 14354] Bad corruption with 2.6.32-rc1 and upwards

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: <200911062207.nA6M7FgC014166@demeter.kernel.org>
Date:	Fri, 6 Nov 2009 22:07:15 GMT
From:	bugzilla-daemon@...zilla.kernel.org
To:	linux-ext4@...r.kernel.org
Subject: [Bug 14354] Bad corruption with 2.6.32-rc1 and upwards

http://bugzilla.kernel.org/show_bug.cgi?id=14354

--- Comment #178 from Linus Torvalds <torvalds@...ux-foundation.org>  2009-11-06 22:07:03 ---
On Fri, 6 Nov 2009, Chris Mason <chris.mason@...cle.com> wrote:
> 
> But I hit a much harder case to fix.  ext4_symlink will log the data blocks
> that hold the symlink name (well ext4_write_begin will log them).
> 
> ext4 uses the generic symlink read helpers, so when we read the link we dive
> into page_getlink() which uses nd_terminate_link to stuff a NULL into the end
> of the link's name.

Gaah. We've had some issues with that before too. Sadly, the name lookup 
routines _really_ want the terminating NUL at the end, so the alternatives 
are to (a) allocate scratch space and copy every time you follow a symlink 
or (b) do major surgery on the name lookup code to take a 'ptr,len' 
approach to names. Both seem nasty.

For ext4, one thing I would suggest is to simply always put the NUL at the 
end of the name, even if the filesystem might not need it. Then 
nd_terminate_link() will still write the NUL, but it won't change any data 
(and thus no CRC's).

That said, I haven't looked at how nasty it would be to change the name 
lookup to use <ptr,len>. Maybe it wouldn't be as horrible as I suspect it 
is (the filesystems themselves wouldn't need changing, since the lowlevel 
filesystem name lookup routines always sees a 'struct dentry' rather than 
the pathname).

                Linus

-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html