<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    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 class="moz-cite-prefix">Am 25.03.25 um 09:54 schrieb Michael
      Geddes via OvmsDev:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAH0p7uJf4XqT-7JTAbTBwiUwyJC5azgJPD4Q3woZNQkKkZT3tw@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <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 gmail_quote_container">
        <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"
            moz-do-not-send="true" class="moz-txt-link-freetext">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" target="_blank" moz-do-not-send="true"
            class="moz-txt-link-freetext">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 * Am Rahmen 5 * D-58313 Herdecke<br>
          Fon 02330 9104094 * Handy 0176 20698926<br>
          <br>
          _______________________________________________<br>
          OvmsDev mailing list<br>
          <a href="mailto:OvmsDev@lists.openvehicles.com"
            target="_blank" moz-do-not-send="true"
            class="moz-txt-link-freetext">OvmsDev@lists.openvehicles.com</a><br>
          <a
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
            rel="noreferrer" target="_blank" moz-do-not-send="true"
            class="moz-txt-link-freetext">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
        </blockquote>
      </div>
      <br>
      <fieldset class="moz-mime-attachment-header"></fieldset>
      <pre wrap="" class="moz-quote-pre">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Michael Balzer * Am Rahmen 5 * D-58313 Herdecke
Fon 02330 9104094 * Handy 0176 20698926</pre>
  </body>
</html>