Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[Bug] mq_open() / mq_unlink() build /dev/mqueue/<name> with rt_sprintf() into a fixed stack buffer, allowing stack overflow

Abierto
  • ¿Algo no está bien?
#11,292 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@manyangshen ya está trabajando en esto.

Desde el 22/9/2026.

  • #11823 de @manyangshen — abierto

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
62/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Tranquilo
Stack tecnológico
c
Área
operating-systems, security

Línea de trabajo

Empieza en components/libc/posix/ipc/mqueue.c, en las ubicaciones indicadas de mq_open() y mq_unlink(), y después revisa los puntos de alcanzabilidad en lwp_syscall.c, en las líneas 9057 y 9122. Verifica la compilación de POSIX mqueue y los casos límite descritos en los pasos de reproducción. La tarea estará terminada cuando ambas rutas rechacen los nombres que no quepan y construyan de forma segura la ruta de la cola sin Stack Overflow.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

RT-Thread Version

master, verified on origin/master at commit 25295501c0cc7181d6a541a867fdf7214879ddf8, first appear in v5.0.2 at commit d6adf6708f6e0666d040e553a81b24edcc92c374

Hardware Type/Architectures

Any architecture using components/libc/posix/ipc/mqueue.c

Develop Toolchain

GCC

Describe the bug
Summary

A stack-based buffer overflow exists in RT-Thread's POSIX message queue implementation.

mq_open() and mq_unlink() build the path string "/dev/mqueue/<name>" into a fixed-size stack buffer using unbounded rt_sprintf().

The buffer is declared as:

char mq_name[RT_NAME_MAX + 12];

However, the required size for the resulting string is:

  • strlen("/dev/mqueue/") + strlen(name) + 1
  • 12 + strlen(name) + 1

So the true safe condition is strlen(name) <= RT_NAME_MAX - 1. Current code does not enforce that condition.

Affected Locations
  • components/libc/posix/ipc/mqueue.c:121
  • components/libc/posix/ipc/mqueue.c:164
  • components/libc/posix/ipc/mqueue.c:465
Vulnerability Details
1. mq_open() contains an off-by-one stack overflow

mq_open() checks:

if (len > RT_NAME_MAX) {
    rt_set_errno(ENAMETOOLONG);
    return (mqd_t)(-1);
}

But it later uses:

rt_sprintf(mq_name, "%s%s", mq_path, name);

with:

char mq_name[RT_NAME_MAX + 12];

Since the prefix "/dev/mqueue/" is 12 bytes and sprintf also writes the terminating NUL byte, len == RT_NAME_MAX already overflows the stack buffer by 1 byte. The current guard is insufficient.

2. mq_unlink() contains an unbounded stack overflow

mq_unlink() uses the same fixed-size stack buffer and the same rt_sprintf() path construction logic, but does not perform an equivalent length check first.

A long name can therefore overflow the stack buffer by more than 1 byte — potentially by an arbitrarily large amount depending on the input length.

Reachability

This is not a remote issue. However, it is practically reachable by local callers.

In systems using LWP/MMU, the syscall layer copies the user-provided message queue name into kernel memory and then invokes mq_open() / mq_unlink() without imposing a stricter length limit that would prevent this bug.

Relevant reachability points:

  • lwp_syscall.c:9057
  • lwp_syscall.c:9122

An untrusted local userspace process can supply an oversized queue name and trigger these kernel-side stack overflows.

Impact
  • Local kernel stack overflow
  • Local denial of service
  • Possible local privilege escalation, depending on platform, compiler, calling convention, stack protector configuration, and surrounding memory layout

If the product does not run untrusted local processes, this may be treated as a severe robustness bug. If the product uses LWP userspace isolation and executes untrusted local code, this is a real local security vulnerability.

Steps to Reproduce
mq_open() off-by-one case

  1. Build RT-Thread with POSIX mqueue support enabled.

  2. Call mq_open() with a queue name whose length is exactly RT_NAME_MAX.

  3. Ensure the path construction reaches:

    rt_sprintf(mq_name, "%s%s", mq_path, name);

  4. Observe that the fixed stack buffer is overrun by 1 byte.

mq_unlink() unbounded case
  1. Build RT-Thread with POSIX mqueue support enabled.
  2. Call mq_unlink() with a very long queue name.
  3. Observe that the same fixed stack buffer is used with rt_sprintf() and no sufficient length guard.
  4. The stack buffer can be overflowed by a larger attacker-controlled amount.
Expected Behavior

RT-Thread should safely construct the queue path without overflowing the stack buffer.

At minimum:

  • Use bounded formatting, e.g. rt_snprintf(mq_name, sizeof(mq_name), "%s%s", mq_path, name)
  • Reject names that cannot fit including the prefix and terminating NUL
  • Treat len >= RT_NAME_MAX as too long in the current buffer sizing scheme
  • Apply the same validation to both mq_open() and mq_unlink()
Actual Behavior
  • mq_open() allows len == RT_NAME_MAX, which causes a deterministic 1-byte stack overflow
  • mq_unlink() uses the same fixed stack buffer and unbounded rt_sprintf() without adequate length validation, allowing larger stack overflows
Suggested Fix
1. Replace unbounded rt_sprintf() with bounded variant
// Before
rt_sprintf(mq_name, "%s%s", mq_path, name);

// After
rt_snprintf(mq_name, sizeof(mq_name), "%s%s", mq_path, name);
2. Fix the off-by-one in mq_open() length check
// Before
if (len > RT_NAME_MAX)

// After
if (len >= RT_NAME_MAX)
3. Add equivalent length validation to mq_unlink()

Apply the same length check before formatting the path, consistent with the corrected mq_open() guard.

Kindly let me know if you intend to request a CVE ID upon confirmation of the vulnerability.

Other additional context

No response

Lenguaje dominante
C
Estrellas
12.3k
Forks
5.5k
Merge medio
4 d 12 h
PR fusionados (30 d)
32

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de RT-Thread/rt-thread

Todos los issues de RT-Thread/rt-thread

Issues similares

Más issues de C

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.