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.)
next prev parent 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