<div dir="auto">That's to make sure a minimum width so that packages shorter than expected dont have issues with the functions accessing it beyond the buffer. <div dir="auto"><br></div><div dir="auto">Oversize will just adapt anyway.</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, 25 Mar 2025, 17:49 Michael Balzer via OvmsDev, <<a href="mailto:ovmsdev@lists.openvehicles.com">ovmsdev@lists.openvehicles.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>

  
    
  
  <div>
    I see you already checked the poll handlers don't write to the
    buffer, so that's a possible & better option.<br>
    <br>
    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.<br>
    <br>
    Regards,<br>
    Michael<br>
    <br>
    <br>
    <div>Am 25.03.25 um 09:54 schrieb Michael
      Geddes via OvmsDev:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div>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 </div>
        <div>in the code won't fumble into uncharted space and we get
          rid of the unchecked copy into the static memory space? </div>
        <div><br>
        </div>
        <div>//.ichael</div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Tue, 25 Mar 2025 at 16:38,
          Michael Balzer via OvmsDev <<a href="mailto:ovmsdev@lists.openvehicles.com" target="_blank" rel="noreferrer">ovmsdev@lists.openvehicles.com</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Wayne,<br>
          <br>
          uh, yes, that's a typical buffer overflow pattern there,
          unguarded <br>
          copying of a string contents to a fixed size buffer:<br>
          <br>
          >   static uint8_t buf[MAX_POLL_DATA_LEN];<br>
          >   memcpy(buf, rxbuf.c_str(), rxbuf.size());<br>
          <br>
          Not sure why/if the handlers need an uint8_t array in the
          first place, <br>
          but a quick first fix should be to adjust MAX_POLL_DATA_LEN:<br>
          <br>
          > #define MAX_POLL_DATA_LEN         196<br>
          <br>
          Add some spare room to the 329 bytes needed, just in case.<br>
          <br>
          Regards,<br>
          Michael<br>
          <br>
          <br>
          Am 25.03.25 um 09:31 schrieb Wayne Love:<br>
          > Hi Micheal,<br>
          ><br>
          > Your comment...<br>
          ><br>
          >> Regarding Leaf CAN problems there ist a running
          investigation here: <br>
          >> <a href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/980" rel="noreferrer noreferrer" target="_blank">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/980</a><br>
          ><br>
          > Is dead on the money.<br>
          ><br>
          > Polling group 61 returns an abnormally large response,
          329 bytes.  <br>
          > This causes a buffer overrun in <br>
          > OvmsVehicleNissanLeaf::IncomingPollReply with an
          unguarded memcpy that <br>
          > causes the module to crash.  Once the module crashes, I
          get the exact <br>
          > symptoms in issue 980.<br>
          ><br>
          > Appreciate your help with this.<br>
          ><br>
          > Thanks<br>
          > Wayne<br>
          ><br>
          ><br>
          ><br>
          <br>
          -- <br>
          Michael Balzer * <a href="https://www.google.com/maps/search/Am+Rahmen+5+*+D-58313+Herdecke?entry=gmail&source=g">Am Rahmen 5 * D-58313 Herdecke</a><br>
          Fon 02330 9104094 * Handy 0176 20698926<br>
          <br>
          _______________________________________________<br>
          OvmsDev mailing list<br>
          <a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank" rel="noreferrer">OvmsDev@lists.openvehicles.com</a><br>
          <a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" rel="noreferrer noreferrer" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
        </blockquote>
      </div>
      <br>
      <fieldset></fieldset>
      <pre>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank" rel="noreferrer">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank" rel="noreferrer">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
    </blockquote>
    <br>
    <pre cols="72">-- 
Michael Balzer * <a href="https://www.google.com/maps/search/Am+Rahmen+5+*+D-58313+Herdecke?entry=gmail&source=g">Am Rahmen 5 * D-58313 Herdecke</a>
Fon 02330 9104094 * Handy 0176 20698926</pre>
  </div>

_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank" rel="noreferrer">OvmsDev@lists.openvehicles.com</a><br>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" rel="noreferrer noreferrer" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</blockquote></div>