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