This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/17478] Fix off-by-one error in pthread_setname_np()
- From: "ryao at gentoo dot org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Thu, 16 Oct 2014 05:09:54 +0000
- Subject: [Bug nptl/17478] Fix off-by-one error in pthread_setname_np()
- Auto-submitted: auto-generated
- References: <bug-17478-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=17478
Richard Yao <ryao at gentoo dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |---
--- Comment #2 from Richard Yao <ryao at gentoo dot org> ---
Andreas, the kernel defines the length to include the NULL terminating
character while strlen() defines the length to exclude it. This causes a
off-by-one error because the concept of how long a string can be is literally
off-by-one. If you pass a string of length 16 according to strlen(), the kernel
will interpret this as a string of length 17 and reject it with EINVAL. The
kernel field is 16 bytes, but in reality, you can only use 15 bytes because the
kernel code for copying the field ensures that the last byte is *ALWAYS* NULL.
I am certain that I am *NOT* setting the name on a different process (although
it is on a different thread). The program that I modified to use this is ZFS'
ztest. It works when I use strncpy() to copy a 16-byte string (according to
`strlen()`) to a 16 byte buffer and then pass that to `pthread_setname_np()`,
but it does not work when I pass the string directly to `pthread_setname_np()`.
If this were another process, it should return EINVAL no matter what the length
of the string is.
--
You are receiving this mail because:
You are on the CC list for the bug.