Bug 206396
| Summary: | Crash while concurrent POSIX semaphore access | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Alexander Saprykin <xelfium> | ||||
| Component: | kern | Assignee: | Jilles Tjoelker <jilles> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | CC: | jilles | ||||
| Priority: | --- | Flags: | jilles:
mfc-stable10+
jilles: mfc-stable9- |
||||
| Version: | 10.2-STABLE | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
A commit references this bug: Author: jilles Date: Fri Jan 22 14:52:31 UTC 2016 New revision: 294565 URL: https://svnweb.freebsd.org/changeset/base/294565 Log: sem: Don't free nameinfo that is still in list when open() fails. This bug could be reproduced easily by calling sem_open() with O_CREAT | O_EXCL on a semaphore that is already open in the process. The struct sem_nameinfo would be freed while still in sem_list and later calls to sem_open() or sem_close() could access freed memory. PR: 206396 MFC after: 5 days Changes: head/lib/libc/gen/sem_new.c head/tools/regression/posixsem2/semtest.c Not amd64-specific. A commit references this bug: Author: jilles Date: Wed Jan 27 22:56:05 UTC 2016 New revision: 294963 URL: https://svnweb.freebsd.org/changeset/base/294963 Log: MFC r294565: sem: Don't free nameinfo that is still in list when open() fails. This bug could be reproduced easily by calling sem_open() with O_CREAT | O_EXCL on a semaphore that is already open in the process. The struct sem_nameinfo would be freed while still in sem_list and later calls to sem_open() or sem_close() could access freed memory. PR: 206396 Changes: _U stable/10/ stable/10/lib/libc/gen/sem_new.c stable/10/tools/regression/posixsem2/semtest.c Fixed in head and stable/10. Thanks for the report. |
Created attachment 165809 [details] Test code I have faced a strange issue with POSIX semaphores. Program crashes when several threads concurrently access POSIX semaphore under the same name. I attached a test code to illustrate it. I have tried to compile this code using Clang and GCC but it was the same result. If you add a pause between threads creation then it executes fine. The same code works fine on Linux and latest DragonFlyBSD.