<html dir="ltr"><head></head><body style="text-align:left; direction:ltr;"><div>On Thu, 2019-10-31 at 16:31 -0700, Ralph Little wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr"><div>Hi,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 31, 2019 at 4:12 PM David McMahon <<a href="mailto:thedjm@gmail.com">thedjm@gmail.com</a>> wrote:<br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><br><div>Thanks for the clue! Looking on that on the settings page of the printer, the hostname is the default of "Canoncbcab3" which seems harmless enough. I changed it to "Can" to see if that changed anything, but still getting the buffer overflow.</div><div>If you have a link handy to that part of the code, can you point me to it? Maybe it's something else right after the strcpy().</div><div> </div></div></div><br></blockquote><div><br></div><div>Hmm, that might have been slightly misleading.</div><div><br></div><div>I'm looking at backend/pixma_bjnp.c at line 801, which is where we see the last successful debug message from the function get_scanner_id():</div><div><br></div><div>"get_scanner_id: Scanner model = ...."<br></div><div></div><div><br></div><div>It returns to the only place it is called, line 1817 in add_scanner().<br></div><div>We don't get the error message (at line 1819) so it must next call the function determine_scanner_serial() which attempts to determine a "serial number" for the scanner.</div><div>This could be one of a selection of things, so that might be the culprit, since it does some strcpy() calls in there, although we don't have any debug messages in there, so we don't really know how far it got before the buffer overrun struck :(</div><div><br></div><div>If it were me chasing this, I would add some more dbg messages to see how far it got, perhaps one after the call to determine_scanner_serial() to see if it returned to start off with. If it didn't some dbg in the function determine_scanner_serial() to see what it decided.<br></div><div><br></div><div>Cheers,</div><div>Ralph</div></div></div>
</blockquote><div><br></div><div>Could be, but it may also be caused by the call to parse_IEEE1284_to_model at the end of get_scanner_id. The use of BJNP_IEEE1284_MAX in the strcpy (already replaced by a mecpy) may be incorrect there. It probably should be a strlen(tok + 4). The next line should be removed, so the code reads (with a bit of readability improvement:</div><div><br></div><div><br></div><div>tatic int</div><div>parse_IEEE1284_to_model (char *scanner_id, char *model)</div><div>{</div><div>/*</div><div> * parses the IEEE1284 ID of the scanner to retrieve make and model</div><div> * of the scanner</div><div> * Returns: 0 = not found</div><div> * 1 = found, model is set</div><div> */</div><div><br></div><div> char s[BJNP_IEEE1284_MAX];</div><div> char *tok;</div><div> char * model_str;</div><div><br></div><div> strncpy (s, scanner_id, BJNP_IEEE1284_MAX);</div><div> s[BJNP_IEEE1284_MAX - 1] = '\0';</div><div> model[0] = '\0';</div><div><br></div><div> tok = strtok (s, ";");</div><div> while (tok != NULL)</div><div> {</div><div> /* MDL contains make and model */</div><div><br></div><div> if (strncmp (tok, "MDL:", 4) == 0)</div><div> {</div><div> model_str = tok +4;</div><div> memcpy (model, model_str, strlen(model_str));</div><div> return 1;</div><div> }</div><div> tok = strtok (NULL, ";");</div><div> }</div><div> return 0;</div><div>}</div><div></div><div><br></div><div>I will include this in my next push to git</div><div><br></div><div>BR, Louis</div><div><br></div><div></div></body></html>