Fix for issue #108 - Make sure the buffer is large enough before ever… #110
Conversation
There was a problem hiding this comment.
The resizing of the global _BUFF takes place at line 270. I don't even see a reason for a global _BUFF (do you). Could you keep your _BUFF_SIZE = const(318) change, and remove the global _BUFF at line 90? Then also remove the global _BUFF declaration at line 268. That will make the code use local buffers in both cases. Then if you could test, that woud be great.
If that works, then _BUFF could be renamed everywhere to buff or buf. Since it's not a global anymore, there's no reason to give it an underscore, all-caps name.
|
Running my eyes over it, I can see no reason at all for _BUFF to be global. And indeed, this is a copy-book example of why globals are bad, because code in function A modifies the global, causing a bug in function B. |
…in both functions that use it
Updating https://github.com/adafruit/Adafruit_CircuitPython_Wiznet5k to 2.4.1 from 2.4.0: > Merge pull request adafruit/Adafruit_CircuitPython_Wiznet5k#107 from BiffoBear/raw_dns > Merge pull request adafruit/Adafruit_CircuitPython_Wiznet5k#110 from dgnuff/dhcp-buffer-overflow > Merge pull request adafruit/Adafruit_CircuitPython_Wiznet5k#106 from BiffoBear/bugfix_socket_send Updating https://github.com/adafruit/Adafruit_CircuitPython_HTTPServer to 2.5.0 from 2.4.0: > Merge pull request adafruit/Adafruit_CircuitPython_HTTPServer#48 from Neradoc/respond-to-file-head > Merge pull request adafruit/Adafruit_CircuitPython_HTTPServer#47 from Neradoc/allow-no-route Updating https://github.com/adafruit/Adafruit_CircuitPython_Bundle/circuitpython_library_list.md to NA from NA: > Updated download stats for the libraries
Added a const value for the buffer size.
Used that value for both the initial buffer allocation, and the buffer re-initialization in preparation for sending packets.
This prevents a buffer overflow when building the DHCPREQUEST packet because the buffer appears to have shrunk while processing the DHCPOFFER reply.