search for: 00001111222233xxyyyy

If the ldlinux being processed is garbage, the search for LDLINUX_MAGIC will overflow its buffer - fix that. I did encounter this issue in Rufus as, due to notorious incompatibilities between different versions of ldlinux.sys and the com32's residing on an ISO, we download a version specific ldlinux.sys from our server... which may get trashed if the user sits behind one of these

...defined behaviour. Maybe boot_image memory always will be a multiple of 4; I don't know. With the proposed patch's uintptr_t stuff, if the magic isn't found: * <------- boot_image_len dictates the final byte * <-------- wp is less than boot_image_len 00001111222233XXYYYY <- XX are out-of-bound bytes * <---- Where wp is when the loop breaks * <------ As far as any kind of pointer should point * <-------- When the loop should break, as 33XX can't contain the magic Fingers crossed that my math is working....

...e if I can work something better here, that could eliminate this cast. > With the proposed patch's uintptr_t stuff, if the magic isn't found: > > * <------- boot_image_len dictates the final byte > * <-------- wp is less than boot_image_len > 00001111222233XXYYYY <- XX are out-of-bound bytes > * <---- Where wp is when the loop breaks > * <------ As far as any kind of pointer should point > * <-------- When the loop should break, as 33XX can't > contain the magic You're right. This...