public inbox for dtrace@lists.linux.dev
 help / color / mirror / Atom feed
From: Nick Alcock <nick.alcock@oracle.com>
To: Kris Van Hees <kris.van.hees@oracle.com>
Cc: dtrace@lists.linux.dev, dtrace-devel@oss.oracle.com
Subject: Re: [DTrace-devel] [PATCH v4 1/5] usdt: get arg types and xlations into DTrace from the DOF
Date: Mon, 04 Nov 2024 15:26:19 +0000	[thread overview]
Message-ID: <877c9jhvfo.fsf@esperi.org.uk> (raw)
In-Reply-To: <ZyVu+Z1Q7IpckIg3@oracle.com> (Kris Van Hees's message of "Fri, 1 Nov 2024 20:14:49 -0400")

On 2 Nov 2024, Kris Van Hees uttered the following:

> On Fri, Nov 01, 2024 at 07:46:04PM -0400, Kris Van Hees via DTrace-devel wrote:
>> Two comments below (one tiny thing, and one explanatory comment that I *think*
>> I have a better suggestion for, but you may want to rephrase it).
>
> Actually, another issue (see below).
>
>> On Fri, Nov 01, 2024 at 03:57:08PM +0000, Nick Alcock via DTrace-devel wrote:
>> > +static size_t
>> > +strings_len(const char *strtab, size_t count)
>> > +{
>> > +	size_t len = 0;
>> > +
>> > +	for (; count > 0; count--) {
>> > +		size_t this_len = strlen(strtab) + 1;
>> > +
>> > +		len += this_len;
>> > +		strtab += this_len;
>> > +	}
>> > +	return len;
>> > +}
>
> What if the strtab blob does not contain enough strings?  There is no check
> here to ensure that you do not start reading past the end of data?

Then we run off the end! We rely on validation already having been done
by validate_provider() (which checks all this stuff), and if that is
buggy we crash and dtprobed restarts us a few times, gives up, logs a
message and rejects the probes. That's the worst that can happen.

We run in a seccomped jail specifically so we don't need to worry about
things like this :)

>> > +	if (dhpb->dthpb_nargc > 0) {
>> > +		size_t	nargs_size;
>> > +
>> > +		nargs_size = strings_len(dhpb->dthpb_ntypes, dhpb->dthpb_nargc);
>
> No validation that there are nargc type strings.
>
>> > +			xargs_size = strings_len(dhpb->dthpb_xtypes,
>> > +						 dhpb->dthpb_xargc);
>
> No validation that there are nargc type strings.

See above.

>> > +			msg_size = offsetof(dof_parsed_t, xargs.args) +
>> > +				   xargs_size;
>> > +
>> > +			msg = malloc(msg_size);
>> > +			if (!msg)
>> > +				goto oom;
>> > +
>> > +			memset(msg, 0, msg_size);
>> > +
>> > +			msg->size = msg_size;
>> > +			msg->type = DIT_ARGS_XLAT;
>> > +			memcpy(msg->xargs.args, dhpb->dthpb_xtypes, xargs_size);
>> > +			dof_parser_write_one(out, msg, msg_size);
>> > +
>> > +			free(msg);
>> > +
>> > +			/* Then the remapping table. */
>> 
>> remapping -> mapping

... I swear I fixed that. Fixed again.

>> > +			msg->size = msg_size;
>> > +			msg->type = DIT_ARGS_MAP;
>> > +			memcpy(msg->argmap.argmap, dhpb->dthpb_args, map_size);
>
> Is there any validation anywhere that there are map_size bytes to read from
> dhpb->dthpb_args?  Is there any validation anywhere here (or in a later patch)
> that the entries are valid (between 0 and nargc)?

Yep! See above: validate_provider checks all of this (you probably
missed it because it's done under another name: see the end of
emit_provider for where we shuffle things into their new homes.)

  reply	other threads:[~2024-11-04 15:26 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-01 15:57 [PATCH v4 0/5] usdt typed args, translators and arg remapping Nick Alcock
2024-11-01 15:57 ` [PATCH v4 1/5] usdt: get arg types and xlations into DTrace from the DOF Nick Alcock
2024-11-01 23:46   ` [DTrace-devel] " Kris Van Hees
2024-11-02  0:14     ` Kris Van Hees
2024-11-04 15:26       ` Nick Alcock [this message]
2024-11-01 15:57 ` [PATCH v4 2/5] dtprobed: stop skipping zero-tracepoint probes in dof_stash.c Nick Alcock
2024-11-01 15:57 ` [PATCH v4 3/5] cg: add argument mapping in the trampoline Nick Alcock
2024-11-02  0:27   ` [DTrace-devel] " Kris Van Hees
2024-11-04 16:41     ` Nick Alcock
2024-11-01 15:57 ` [PATCH v4 4/5] usdt: typed args and arg mapping Nick Alcock
2024-11-02  1:09   ` Kris Van Hees
2024-11-04 16:38     ` Nick Alcock
2024-11-01 15:57 ` [PATCH v4 5/5] usdt: fix create_underlying error path Nick Alcock

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=877c9jhvfo.fsf@esperi.org.uk \
    --to=nick.alcock@oracle.com \
    --cc=dtrace-devel@oss.oracle.com \
    --cc=dtrace@lists.linux.dev \
    --cc=kris.van.hees@oracle.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