[DTrace-devel] [PATCH] Fix size of string data in the trace output buffer
Kris Van Hees
kris.van.hees at oracle.com
Wed Sep 8 08:51:03 PDT 2021
On Wed, Sep 08, 2021 at 10:52:53AM -0400, Eugene Loh wrote:
> On 9/8/21 2:30 AM, Kris Van Hees wrote:
>
> > On Wed, Sep 08, 2021 at 12:49:12AM -0400, Eugene Loh wrote:
> >> Also, does dt_cg_store_var() have the same issues?
> > No, this is only really needed for store_val because of how the consumer
> > handles strings.
>
> Let's put it this way: dt_cg_store_var() has issues. Perhaps they are
> not the "same" issues since they have nothing to do with the consumer,
> but the fix (replacing a straight copy with a custom prefix+data+NULL
> construction) would be the same. E.g., you have a test case:
> #pragma D option strsize=5
> BEGIN
> {
> trace(probeprov);
> }
> If we modified that to be:
> #pragma D option strsize=5
> BEGIN
> {
> p = "dtrace";
> trace(p);
> }
> the BPF verifier would erupt. I think that's because in
> dt_cg_store_var(), we assume we'll have enough space to copy over the
> string. We probably need, instead, well, basically the same fix you
> give in this patch. If you like, I can propose a patch. Or, we can
> wait... especially if the length prefix is going away anyhow.
Ah, correct. Fixing now. I overlooked that string constants not getting
capped at compile time would still be able to cause an overrun here when
storing to variables.
More information about the DTrace-devel
mailing list