Ushering out strlcpy()

Posted Aug 25, 2022 18:15 UTC (Thu) by adobriyan (subscriber, #30858)
Parent article: Ushering out strlcpy()

> Finally, strlcpy() is subject to a race condition.

No, it doesn't count! It's like saying that strdup() has race condition because it calls strlen() inside. Of course, string must be stable during strlcpy().

to post comments

Ushering out strlcpy()

Posted Aug 25, 2022 22:04 UTC (Thu) by roc (subscriber, #30627) [Link] (3 responses)

Yes. In fact any C code reading memory without using atomics, where that memory is concurrently modified, is undefined behaviour. So all C implementations of string copying will be "subject to a race condition" in that sense.

Ushering out strlcpy()

Posted Aug 25, 2022 22:42 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (2 responses)

I will guess that while what you wrote is literally true, the same reasoning applies for almost everything Linux (as an operating system kernel written largely in C) does and so Linus will pronounce it stupid and decide it doesn't apply.

Mechanically, reading a byte and then writing the byte works, the data you get might have tearing, but it's still just bytes. Byte 14 of a 20 byte structure you copied might, unaccountably, be 0xF6 even though that's inconsistent with the other bytes, but it can't actually take some eldritch value outside of the 256 possible bit patterns. If you're writing a GTK+ mail app, you just shouldn't think this way, it's going to get you into trouble - but if you're writing an operating system kernel this is far from the shakiest proposition you're relying on.

Anyway, I think the race condition is a practical problem for untrusted input. If I know the kernel will read my program's buffer, find there's a NUL byte in position 814, and then cheerfully copy 814 bytes into some other structure expecting the result to be a 814 byte C-style string, then I can cause some real mischief, which might have been impossible to pull off if the kernel page-copies my entire data structure instead.

Ushering out strlcpy()

Posted Aug 26, 2022 2:12 UTC (Fri) by dezgeg (guest, #92243) [Link] (1 responses)

> Anyway, I think the race condition is a practical problem for untrusted input. If I know the kernel will read my program's buffer, find there's a NUL byte in position 814, and then cheerfully copy 814 bytes into some other structure expecting the result to be a 814 byte C-style string, then I can cause some real mischief, which might have been impossible to pull off if the kernel page-copies my entire data structure instead.

Yes, userspace trying to trick the kernel is a valid concern... but I do not get how that is related to strlcpy() topic at all as that function is not anyway safe to call on a userspace pointer!

This whole untrusted and/or racy source argument to strlcpy() is something I don't understand at all... if there is no guarantee on source string being NUL-terminated, then strscpy() will read past the source buffer if it happens to be smaller than the destination buffer.

Ushering out strlcpy()

Posted Aug 26, 2022 7:42 UTC (Fri) by LtWorf (subscriber, #124958) [Link]

I think it will read past regardless of the size of the destination buffer.