From: David Howells <dhowells@redhat.com>
To: David Wysochanski <dwysocha@redhat.com>
Cc: dhowells@redhat.com, Dan Carpenter <dan.carpenter@oracle.com>,
linux-nfs <linux-nfs@vger.kernel.org>
Subject: Re: [bug report] nfs: Convert to new fscache volume/cookie API
Date: Fri, 03 Dec 2021 16:06:16 +0000 [thread overview]
Message-ID: <997841.1638547576@warthog.procyon.org.uk> (raw)
In-Reply-To: <CALF+zOkZgtfP7HrX4oP=qx2uKr3FTRHqECRqKGkRBZaz6F-jdg@mail.gmail.com>
David Wysochanski <dwysocha@redhat.com> wrote:
> > 29 if (*_len > NFS_MAX_KEY_LEN)
> > 30 return false;
> > 31 if (x == 0)
> > --> 32 key[(*_len)++] = ',';
> > 33 else
> > 34 *_len += sprintf(key + *_len, ",%llx", x);
> > 35 return true;
> > 36 }
> >
> > This function is very badly broken. As the checker suggests, the >
> > should be >= to prevent an array overflow. But it's actually off by
> > two because we have to leave space for the NUL terminator so the buffer
> > is full when "*_len == NFS_MAX_KEY_LEN - 1". That means the check
> > should be:
> >
> > if (*_len >= NFS_MAX_KEY_LEN - 1)
> > return false;
It shouldn't ever overflow the array. The sprintf really shouldn't insert
more than 18 chars (comma, 16 hex digits and a NUL), but the allocated space
has a 24-char excess to handle that.
Maybe I should use:
static inline unsigned int how_many_hex_digits(unsigned int x)
{
return x ? round_up(ilog2(x) + 1, 4) / 4 : 0;
}
from fs/cachefiles/key.c to determine how much space I'm actually going to
use.
Actually, I would very much rather not include the comms parameters if I can
avoid it. They aren't really something that distinguishes volumes on servers
- they're purely a local phenomenon to distinguish local *mounts* made with
different parameters (for which nfs has different superblocks!).
David
next prev parent reply other threads:[~2021-12-03 16:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-01 8:54 [bug report] nfs: Convert to new fscache volume/cookie API Dan Carpenter
2021-12-03 13:39 ` David Wysochanski
2021-12-03 16:06 ` David Howells [this message]
2021-12-03 20:05 ` David Wysochanski
2021-12-06 9:28 ` David Howells
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=997841.1638547576@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=dan.carpenter@oracle.com \
--cc=dwysocha@redhat.com \
--cc=linux-nfs@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.