Kernel buffer overflow exposes iPhone 11 Pro to radio based attacks

Patrick Schluter Patrick.Schluter at bbox.fr
Wed Dec 9 08:54:23 UTC 2020


On Wednesday, 9 December 2020 at 08:52:10 UTC, Patrick Schluter 
wrote:
> On Wednesday, 9 December 2020 at 08:26:35 UTC, Patrick Schluter 
> wrote:
>> On Wednesday, 2 December 2020 at 17:52:29 UTC, H. S. Teoh 
>> wrote:
>>>[...]
>>
>> The only sin of strncpy() is its name. The problem is that 
>> people think it is a string function (even you fell for it), 
>> but it never was a string function, it is a buffer function 
>> and a mem*/buf* prefix would have gone a long way to avoid its 
>> misuse as a string function. Beyond its truncation feature, it 
>> has a second functionality that most people do not know and 
>> that make it definitely different from the string function, it 
>> overwrites the whole buffer with 0 to the end of it, making it 
>> often a performance hog:
>>
>> [...]
> Simplest implementation of strncpy
>
>     char *strncpy(char *dest, const char *src, size_t n)
>     {
>       memset(dest, 0, n);
>       memcpy(dest, src, min(strlen(src),n));

      return memcpy(dest, src, min(strlen(src), n));

obviously

>     }
>
> Checking the man on Linux does perpetuate the error. strncpy() 
> is joined with strcpy(), which is wrong imo. As my 
> implementation above shows, strncpy() is semantically closer to 
> memcpy() than to strcpy().




More information about the Digitalmars-d mailing list