From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: sandeen@redhat.com, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 01/14] xfs_scrub: avoid buffer overflow when scanning attributes
Date: Tue, 10 Apr 2018 17:20:53 -0700 [thread overview]
Message-ID: <20180411002053.GD12977@magnolia> (raw)
In-Reply-To: <d293fe79-73bd-220f-0148-ee82c98d8a9f@sandeen.net>
On Tue, Apr 03, 2018 at 12:30:57PM -0500, Eric Sandeen wrote:
> On 3/20/18 10:39 PM, Darrick J. Wong wrote:
> > From: Darrick J. Wong <darrick.wong@oracle.com>
> >
> > Avoid a buffer overflow when we're formatting extended attribute names
> > for name checking.
>
> This won't /actually/ overflow, right, because you are doing
> snprintf(NAME_MAX) into a buffer of size [NAME_MAX + 1].
>
> However, it might truncate the attribute string if too long.
> (just trying to avoid security folk wig-outs).
>
> > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> > ---
> > scrub/phase5.c | 8 +++++---
> > 1 file changed, 5 insertions(+), 3 deletions(-)
> >
> >
> > diff --git a/scrub/phase5.c b/scrub/phase5.c
> > index 8e0a1be..36821d0 100644
> > --- a/scrub/phase5.c
> > +++ b/scrub/phase5.c
> > @@ -143,6 +143,8 @@ static const struct xfs_attr_ns attr_ns[] = {
> > {ATTR_SECURE, "secure"},
> > {0, NULL},
> > };
> > +/* Enough space to handle the prefix. */
> > +#define ATTR_NAME_MAX (NAME_MAX + 8)
>
> Unrelated to this change, really, but should NAME_MAX be
> XATTR_NAME_MAX for clarity & consistency w/ the xattr code?
>
> (it's defined in /usr/include/linux/limits.h)
Hm, I got bogged down here trying to figure out if XATTR_NAME_MAX
applied to the entire string "security.foo" or just the ".foo" part.
The answer is (according to getxattr()) the first, so I'll fix this to
use XATTR_NAME_MAX directly...
>
> >
> > /*
> > * Check all the xattr names in a particular namespace of a file handle
> > @@ -158,7 +160,7 @@ xfs_scrub_scan_fhandle_namespace_xattrs(
> > {
> > struct attrlist_cursor cur;
> > char attrbuf[XFS_XATTR_LIST_MAX];
> > - char keybuf[NAME_MAX + 1];
> > + char keybuf[ATTR_NAME_MAX + 1];
> > struct attrlist *attrlist = (struct attrlist *)attrbuf;
> > struct attrlist_ent *ent;
> > struct unicrash *uc;
> > @@ -172,14 +174,14 @@ xfs_scrub_scan_fhandle_namespace_xattrs(
> >
> > memset(attrbuf, 0, XFS_XATTR_LIST_MAX);
> > memset(&cur, 0, sizeof(cur));
> > - memset(keybuf, 0, NAME_MAX + 1);
> > + memset(keybuf, 0, ATTR_NAME_MAX + 1);
> > error = attr_list_by_handle(handle, sizeof(*handle), attrbuf,
> > XFS_XATTR_LIST_MAX, attr_ns->flags, &cur);
> > while (!error) {
> > /* Examine the xattrs. */
> > for (i = 0; i < attrlist->al_count; i++) {
> > ent = ATTR_ENTRY(attrlist, i);
> > - snprintf(keybuf, NAME_MAX, "%s.%s", attr_ns->name,
>
> To future proof this rather than relying on a hardcoded 8 based on the
> current namespaces above, how about:
>
> #define XATTR_NS_MAX 8
> #define ATTR_STRING_MAX (XATTR_NS_MAX + XATTR_NAME_MAX + 1) /* for '.' */
>
> char keybuf[ATTR_STRING_MAX + 1];
...and then we can use it directly here instead of all these weird
NAME_MAX variants.
>
> ASSERT(strlen(attr_ns->name) <= XATTR_NS_MAX);
> snprintf(keybuf, ATTR_STRING_MAX, "%s.%s", attr_ns->name,
> ent->a_name);
>
> just in case someone adds a new
>
> ATTR_SUPERDELUXE, "superdeluxe"
>
> namespace some day? Is that overkill?
No, not overkill.
--D
>
> > + snprintf(keybuf, ATTR_NAME_MAX, "%s.%s", attr_ns->name,
> > ent->a_name);
> > moveon = xfs_scrub_check_name(ctx, descr,
> > _("extended attribute"), keybuf);
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
next prev parent reply other threads:[~2018-04-11 0:21 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-21 3:39 [PATCH 00/14] xfsprogs: online scrub fixes Darrick J. Wong
2018-03-21 3:39 ` [PATCH 01/14] xfs_scrub: avoid buffer overflow when scanning attributes Darrick J. Wong
2018-04-03 17:30 ` Eric Sandeen
2018-04-05 3:57 ` Darrick J. Wong
2018-04-11 0:20 ` Darrick J. Wong [this message]
2018-04-11 0:27 ` [PATCH v2 " Darrick J. Wong
2018-03-21 3:39 ` [PATCH 02/14] xfs_scrub: only run ascii name checks if unicode name checker Darrick J. Wong
2018-04-03 17:49 ` Eric Sandeen
2018-03-21 3:39 ` [PATCH 03/14] xfs_scrub: don't complain about different normalization Darrick J. Wong
2018-04-10 23:37 ` Eric Sandeen
2018-03-21 3:40 ` [PATCH 04/14] xfs_scrub: communicate name problems via flagset instead of booleans Darrick J. Wong
2018-04-10 23:46 ` Eric Sandeen
2018-03-21 3:40 ` [PATCH 05/14] xfs_scrub: make name_entry a first class structure Darrick J. Wong
2018-03-21 3:40 ` [PATCH 06/14] xfs_scrub: transition from libunistring to libicu for Unicode processing Darrick J. Wong
2018-03-21 3:40 ` [PATCH 07/14] xfs_scrub: check name for suspicious characters Darrick J. Wong
2018-03-21 3:40 ` [PATCH 08/14] xfs_scrub: use Unicode skeleton function to find confusing names Darrick J. Wong
2018-03-26 19:58 ` [PATCH v2 " Darrick J. Wong
2018-03-21 3:40 ` [PATCH 09/14] xfs_scrub: don't warn about confusing names if dir/file only writable by root Darrick J. Wong
2018-03-26 19:59 ` [PATCH v2 " Darrick J. Wong
2018-03-21 3:40 ` [PATCH 10/14] xfs_scrub: refactor mountpoint finding code to use libfrog path code Darrick J. Wong
2018-04-11 1:48 ` Eric Sandeen
2018-03-21 3:40 ` [PATCH 11/14] xfs_scrub_all: report version Darrick J. Wong
2018-04-11 0:28 ` Eric Sandeen
2018-03-21 3:40 ` [PATCH 12/14] xfs_scrub: disable private /tmp for scrub service Darrick J. Wong
2018-04-11 1:45 ` Eric Sandeen
2018-04-11 1:49 ` Darrick J. Wong
2018-04-11 1:53 ` [PATCH v2 " Darrick J. Wong
2018-03-21 3:41 ` [PATCH 13/14] xfs_scrub_all: escape paths being passed to systemd service instances Darrick J. Wong
2018-04-11 1:31 ` Eric Sandeen
2018-03-21 3:41 ` [PATCH 14/14] xfs_scrub_all: use system encoding for lsblk output decoding Darrick J. Wong
2018-04-11 1:35 ` Eric Sandeen
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=20180411002053.GD12977@magnolia \
--to=darrick.wong@oracle.com \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@redhat.com \
--cc=sandeen@sandeen.net \
/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).