Closed hac425xxx closed 3 years ago
Thanks for the report - I believe I've now addresses these in the latest commits. I've ended up removing the cruddy TCP/IP code from the examples entirely, as it was more of a learning exercise for myself over a decade ago than practical code for others to use.
I've added the missing length checks in the other cases.
The fix is broken. You checking if requested length is >= buffer size. This will reject requests with == buffer size. What is a normal buffer size and should be allowed! Try to reject only if >... https://github.com/abcminiuser/lufa/blob/336f3570a7e6c566fe62084414eb0464ba0ccf40/Projects/AVRISP-MKII/Lib/XPROG/XPROGProtocol.c#L352
It's also part of my PR... But i think it should be repaired instantly for allowing to use XPROGProtocol without stall again^^
Regards
Quite right @masterxq - will patch now.
multiple buffer overflow vulnerabilities in lufa
Stack Overflow in CCID_Task
path
it first receive data to
USB_CCID_BulkMessage_Header_t
then in
CCID_PC_to_RDR_XfrBlock
, it could readCCIDHeader.Length
data toRequestBuffer
if
CCIDHeader.Length > sizeof(RequestBuffer)
, it could overflow.buffer overflow in EVENT_USB_Device_ControlRequest
path
code
if
USB_ControlRequest.wLength > sizeof(RNDISMessageBuffer)
, it could overflow.out of bound access in IP_ProcessIPPacket
path:
code
if
IPHeaderIN->HeaderLength > the size of InDataStart
, it could out of bound!buffer overflow in RNDIS_Device_ProcessControlRequest
path:
code
if
USB_ControlRequest.wLength > the size of MessageBuffer
, it could buffer overflow!stack overflow in ISPProtocol_SPIMulti
path:
code
if
SPI_Multi_Params.TxBytes > the size of SPI_Multi_Params.TxData
, it could buffer overflow!stack overflow in XPROGProtocol_WriteMemory
path:
code
if
WriteMemory_XPROG_Params.Length > the size of WriteMemory_XPROG_Params.ProgData
, it could buffer overflow!stack overflow in XPROGProtocol_ReadMemory
path:
code
if
ReadMemory_XPROG_Params.Length > the size of ReadBuffer
, it could buffer overflow!