[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID:
<DB9PR02MB68570D7295BAF424A011E540B7382@DB9PR02MB6857.eurprd02.prod.outlook.com>
Date: Mon, 11 May 2026 09:24:45 +0000
From: SanthoshKumar Selvaraj <santhosh.kumar.selvaraj@...io>
To: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: sem_open and shm_open share the same namespace via __shm_mapname
Hi,
I'd like to report a namespace collision between sem_open and shm_open in musl's POSIX IPC implementation.
The Problem
Both shm_open (src/mman/shm_open.c) and sem_open (src/thread/sem_open.c) uses same __shm_mapname function to construct the name, which maps any name to /dev/shm/<name>:
// src/mman/shm_open.c
char *__shm_mapname(const char *name, char *buf)
{
...
memcpy(buf, "/dev/shm/", 9);
memcpy(buf+9, name, p-name+1);
return buf;
}
As a result, shm_open("/test") and sem_open("/test") both resolve to /dev/shm/test, causing them to collide when the same name is used for both a shared memory object and a named semaphore.
Expected Behaviour (POSIX / glibc)
The POSIX specification treats shared memory objects and named semaphores as separate namespaces. glibc enforces this by adding a sem. prefix in its sem_open path construction:
shm_open("/test") → /dev/shm/test
sem_open("/test") → /dev/shm/sem.test
This is observable in practice: on glibc systems, a shared memory object and a semaphore with the same logical name coexist without conflict. On musl-based systems (Alpine Linux, embedded MUSL targets), they collide.
Impact
Any library or application that internally uses a named semaphore derived from a shared memory name — without expecting a collision — will silently fail or corrupt state on musl.
A concrete example is Qt's QSharedMemory, which creates an accompanying QSystemSemaphore for locking using the same base name. To avoid this, Qt has had to add a platform-specific workaround for all musl targets to append _shm / _sem suffixes to avoid the collision or similar to glibc way of "sem." prefix.
Suggested Fix
In src/thread/sem_open.c, construct the semaphore path with a sem. prefix rather than reusing __shm_mapname directly:
// Instead of:
if (!(name = __shm_mapname(name, buf)))
return SEM_FAILED;
// Use a semaphore-specific path, e.g.:
// /dev/shm/sem.<name>
This would align musl's behaviour with glibc and the established convention, without breaking existing semaphore-only code.
Thanks & Regards, SanthoshKumar Selvaraj Qt Company
Confidential
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
