linux-kernel - Re: [v2.6.34-stable 013/165] xfs: Fix possible memory corruption in xfs

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:	Fri, 17 Aug 2012 12:38:55 -0300
From:	Herton Ronaldo Krzesinski <herton.krzesinski@...onical.com>
To:	Paul Gortmaker <paul.gortmaker@...driver.com>
Cc:	stable@...r.kernel.org, linux-kernel@...r.kernel.org,
	Carlos Maiolino <cmaiolino@...hat.com>,
	Alex Elder <aelder@....com>, Jan Kara <jack@...e.cz>,
	Ben Myers <bpm@....com>, Dave Chinner <dchinner@...hat.com>
Subject: Re: [v2.6.34-stable 013/165] xfs: Fix possible memory corruption in
 xfs_readlink

On Wed, Aug 15, 2012 at 03:45:57PM -0400, Paul Gortmaker wrote:
> From: Carlos Maiolino <cmaiolino@...hat.com>
> 
>                    -------------------
>     This is a commit scheduled for the next v2.6.34 longterm release.
>     http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
>     If you see a problem with using this for longterm, please comment.
>                    -------------------
> 
> commit b52a360b2aa1c59ba9970fb0f52bbb093fcc7a24 upstream.
> 
> Fixes a possible memory corruption when the link is larger than
> MAXPATHLEN and XFS_DEBUG is not enabled. This also remove the
> S_ISLNK assert, since the inode mode is checked previously in
> xfs_readlink_by_handle() and via VFS.
> 
> Updated to address concerns raised by Ben Hutchings about the loose
> attention paid to 32- vs 64-bit values, and the lack of handling a
> potentially negative pathlen value:
>  - Changed type of "pathlen" to be xfs_fsize_t, to match that of
>    ip->i_d.di_size
>  - Added checking for a negative pathlen to the too-long pathlen
>    test, and generalized the message that gets reported in that case
>    to reflect the change
> As a result, if a negative pathlen were encountered, this function
> would return EFSCORRUPTED (and would fail an assertion for a debug
> build)--just as would a too-long pathlen.
> 
> Signed-off-by: Alex Elder <aelder@....com>
> Signed-off-by: Carlos Maiolino <cmaiolino@...hat.com>
> Reviewed-by: Christoph Hellwig <hch@....de>
> [PG: no xfs_alert in 2.6.34; use xfs_fs_cmn_err(CE_ALERT, ...) instead]
> Signed-off-by: Paul Gortmaker <paul.gortmaker@...driver.com>
[...]

commit 9b025eb3a89e041bab6698e3858706be2385d692 ("xfs: Fix missing
xfs_iunlock() on error recovery path in xfs_readlink()") addresses a
regression with this change, something to consider for inclusion too.

-- 
[]'s
Herton
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/