[Ovmsdev] Leaf AZE1 Can1 stuck after poll 7BB group 61

[Michael Geddes]

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?

//.ichael

On Tue, 25 Mar 2025 at 16:38, Michael Balzer via OvmsDev <
ovmsdev at lists.openvehicles.com> wrote:

> Wayne,
>
> uh, yes, that's a typical buffer overflow pattern there, unguarded
> copying of a string contents to a fixed size buffer:
>
> >   static uint8_t buf[MAX_POLL_DATA_LEN];
> >   memcpy(buf, rxbuf.c_str(), rxbuf.size());
>
> 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
> >
> >
> >
>
> --
> Michael Balzer * Am Rahmen 5 * D-58313 Herdecke
> Fon 02330 9104094 * Handy 0176 20698926
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20250325/c0d057bd/attachment.htm>