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
>
>
>