I see you already checked the poll handlers don't write
to the buffer, so that's a possible & better option.
But why do you limit the reserve() call? Clearly, the
MAX_POLL_DATA_LEN isn't sufficient for the new poll, Wayne
wants to add. Doing rxbuf.reserve(length + job.mlremain)
should be perfectly OK, as it adapts to any reply size?
After all, it's just a reservation, append will need to
reallocate if it's too small. I think the module can get rid
off MAX_POLL_DATA_LEN altogether when using the string
memory directly.
Regards,
Michael
Am 25.03.25 um 09:54 schrieb Michael Geddes via
OvmsDev:
Why don't we just std:max() the reserve() on the
string and cast c_str() to uint8_t * !? That way we
know the array access
in the code won't fumble into uncharted space and
we get rid of the unchecked copy into the static
memory space?
Not sure why/if the handlers need an uint8_t array in
the first place,
but a quick first fix should be to adjust
MAX_POLL_DATA_LEN:
> #define MAX_POLL_DATA_LEN 196
Add some spare room to the 329 bytes needed, just in
case.
Regards,
Michael
Am 25.03.25 um 09:31 schrieb Wayne Love:
> Hi Micheal,
>
> Your comment...
>
>> Regarding Leaf CAN problems there ist a
running investigation here:
>> https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/980
>
> Is dead on the money.
>
> Polling group 61 returns an abnormally large
response, 329 bytes.
> This causes a buffer overrun in
> OvmsVehicleNissanLeaf::IncomingPollReply with an
unguarded memcpy that
> causes the module to crash. Once the module
crashes, I get the exact
> symptoms in issue 980.
>
> Appreciate your help with this.
>
> Thanks
> Wayne
>
>
>