From: Eric Sandeen <sandeen@sandeen.net>
To: Christoph Hellwig <hch@infradead.org>
Cc: Carlos Maiolino <cmaiolino@redhat.com>, xfs@oss.sgi.com
Subject: Re: [PATCH] Fix possible memory corruption in xfs_readlink
Date: Mon, 17 Oct 2011 12:24:09 -0500 [thread overview]
Message-ID: <4E9C64B9.7070308@sandeen.net> (raw)
In-Reply-To: <20111017140030.GA19136@infradead.org>
On 10/17/11 9:00 AM, Christoph Hellwig wrote:
> This generally good, but you'll need to fix formatting a bit
> for both the mail body and the patch itself.
>
> On Mon, Oct 17, 2011 at 01:30:12PM -0200, Carlos Maiolino wrote:
>> Fixes a possible memory corruption when the link
>> is larger than MAXPATHLEN and XFS_DEBUG is not
>> enabled.
>> This also uses S_IFLNK to check link not only
>> in DEBUG mode.
>
> Please try to fill up ~ 75 characters for each line in the mail body,
> e.g.
>
> Fix a possible memory corruption when a symlink target is larger than
> MAXPATHLEN and XFS_DEBUG is not enabled. Also use S_IFLNK to check
> against disk corruption in di_mode for non-debug mode.
>
> (I've also update the content a little bit).
>
>> - ASSERT(S_ISLNK(ip->i_d.di_mode));
>> - ASSERT(ip->i_d.di_size <= MAXPATHLEN);
>> + if (!(S_ISLNK(ip->i_d.di_mode)) || !(ip->i_d.di_size <= MAXPATHLEN )){
>> +
>> + xfs_emerg(mp, "inode (%lld), link too long or not a link",
>> + (unsigned long long)ip->i_ino);
>> + ASSERT(0);
>> + return XFS_ERROR(EFSCORRUPTED);
>> + }
>
> No need for the inner braces in both branches, but per kernel coding
> style there should be one before the opening brace. Also no spaces
> before the closing round braces, please. I also think it would be
> cleanrer to split this into two checks, as it's two possible
> corruptions, e.g.
>
> if (!S_ISLNK(ip->i_d.di_mode)) {
> xfs_emerg(mp, "inode (%lld) not a link in %s\n",
> (unsigned long long)ip->i_ino), __func__);
> ASSERT(0);
> return XFS_ERROR(EFSCORRUPTED);
> }
We could get here via xfs_readlink_by_handle, but that tests
S_ISLNK(dentry->d_inode->i_mode) before calling xfs_readlink.
I'm guessing that we wouldn't get here through normal paths
if the inode in question weren't a symlink, so is there any need
to re-test ip->i_d.di_mode here at runtime?
I'm not sure both ASSERTS necessarily need to be turned into runtime tests.
The 2nd does, clearly, so we don't overflow the buffer. Just not sure about
the first.
> if (ip->i_d.di_size > MAXPATHLEN) {
> xfs_emerg(mp, "inode (%lld) larger than MAXPATHLEN in %s\n",
> (unsigned long long)ip->i_ino), __func__);
> ASSERT(0);
> return XFS_ERROR(EFSCORRUPTED);
> }
Since we assign "pathlen" a little later, it might be prettier to use that
variable at that point? It's there, and it's descriptive.
Also, the current xfs_emerg() convention seems to be:
function: problem description
It might we worth following that, i.e.
xfs_emerg(mp, "%s: symlink target in inode %lld too long (%lld)", __func__, ip->i_ino, pathlen)
-Eric
> It might also be useful to print the length in the second case as that
> would help debugging potential corruptions. (e.g. single bit flips)
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-10-17 17:24 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-17 15:30 [PATCH] Fix possible memory corruption in xfs_readlink Carlos Maiolino
2011-10-17 14:00 ` Christoph Hellwig
2011-10-17 17:24 ` Eric Sandeen [this message]
-- strict thread matches above, loose matches on Subject: below --
2011-10-17 21:05 Carlos Maiolino
2011-10-17 22:39 ` Alex Elder
2011-10-17 22:43 ` Dave Chinner
2011-10-18 1:28 ` Carlos Maiolino
2011-10-18 4:18 Carlos Maiolino
2011-10-18 6:52 ` Christoph Hellwig
2011-10-18 13:59 ` Alex Elder
2011-10-18 14:25 ` Eric Sandeen
2011-11-01 14:14 Ben Hutchings
2011-11-02 17:52 ` Alex Elder
2011-11-02 19:45 ` Christoph Hellwig
2011-11-02 20:22 ` Alex Elder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E9C64B9.7070308@sandeen.net \
--to=sandeen@sandeen.net \
--cc=cmaiolino@redhat.com \
--cc=hch@infradead.org \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox