From: Christoph Hellwig <hch@infradead.org>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 1/3] xfs: ubsan fixes
Date: Thu, 14 Dec 2017 08:33:37 -0800 [thread overview]
Message-ID: <20171214163337.GA11003@infradead.org> (raw)
In-Reply-To: <151189079681.14861.10709810493861130558.stgit@magnolia>
On Tue, Nov 28, 2017 at 09:39:56AM -0800, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@oracle.com>
>
> Fix some complaints from the UBSAN about signed integer addition overflows.
>
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
I only noticed that now that it's in Linus' tree. Need to find some
more time for the XFS list..
> - if (offset + count > mp->m_super->s_maxbytes)
> + if ((xfs_ufsize_t)offset + count > mp->m_super->s_maxbytes)
> count = mp->m_super->s_maxbytes - offset;
I don't think this fix is useful in any meaninfless way. Yes,
signed overflow in C is undefined, and unsigned overflow is and this
will shut up UBSAN. But it doesn't solve the problem at all.
Assuming we still need these checks and the VFS doesn't take care of
it already (I'd need to double check) we want to truncate at s_maxbytes,
and assuming s_maxbytes is close to ULLONG_MAX and count makes it
overflow this will give the wrong result, as it won't cap anything.
What we'd need instead would be something like:
if (offset > mp->m_super->s_maxbytes - count)
count = mp->m_super->s_maxbytes - offset;
as that does the right thing.
prev parent reply other threads:[~2017-12-14 16:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-28 17:39 [PATCH 1/3] xfs: ubsan fixes Darrick J. Wong
2017-11-28 17:40 ` [PATCH 2/3] xfs: remove unused parameter from xfs_writepage_map Darrick J. Wong
2017-11-30 13:47 ` Brian Foster
2017-11-28 17:40 ` [PATCH 3/3] xfs: scrub inode mode properly Darrick J. Wong
2017-11-30 13:47 ` Brian Foster
2017-11-30 13:47 ` [PATCH 1/3] xfs: ubsan fixes Brian Foster
2017-12-14 16:33 ` Christoph Hellwig [this message]
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=20171214163337.GA11003@infradead.org \
--to=hch@infradead.org \
--cc=darrick.wong@oracle.com \
--cc=linux-xfs@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).