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

# parseCmdLine() wraps multi-word Linux-unikernel args in unescaped single quotes, corrupting urunit's boot-cmdline argument parsing when an arg itself contains a quote

Abierto
#897 4 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
76/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Tranquilo
Stack tecnológico
go

Línea de trabajo

Empieza en pkg/unikontainers/unikernels/linux.go, leyendo parseCmdLine() junto con CommandString() y la reproducción citada. Sigue cómo Process.Args se convierte en el parámetro de arranque init= del guest y verifica después que los argumentos que contienen tanto espacios en blanco como una comilla simple sigan pudiendo ser recuperados por urunit sin cambiar los demás argumentos. Se considera terminado cuando el caso reproducido del unikernel de Linux conserva los límites originales de los argumentos o devuelve un error claro.

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

Descripción

invalid

What happened:
When urunc runs a Linux-based unikernel guest (the linux unikernel type, driven by the urunit init process), it builds the guest's init= boot-parameter string by joining Process.Args from the OCI spec. To let urunit recover which whitespace-separated tokens belong to one original argument, parseCmdLine() wraps any argument containing a space in single quotes, via plain string concatenation, with no escaping of quote characters already present in the argument.

Root cause:
pkg/unikontainers/unikernels/linux.go:248-272:

func (l *Linux) parseCmdLine(cmdLine []string) error {
	if len(cmdLine) == 0 {
		return fmt.Errorf("no init was specified")
	}

	// Wrap multi-word arguments in quotes for urunit compatibility.
	normalizedArgs := make([]string, len(cmdLine))
	for i, arg := range cmdLine {
		arg = strings.TrimSpace(arg)
		if strings.Contains(arg, " ") {
			normalizedArgs[i] = "'" + arg + "'"
		} else {
			normalizedArgs[i] = arg
		}
	}

	l.App = normalizedArgs[0]
	if len(normalizedArgs) > 1 {
		l.Command = strings.Join(normalizedArgs[1:], " ")
	} else {
		l.Command = ""
	}

	return nil
}

l.App/l.Command are then concatenated unescaped into the guest kernel boot parameters in CommandString() at pkg/unikontainers/unikernels/linux.go:124-126:

if l.App != "" {
	initParams := rdinit + "init=" + l.App + " -- " + l.Command
	bootParams += " " + initParams
}

If an argument contains both a space and a single quote, for example sh -c "echo it's fine", the naive "'" + arg + "'" wrap produces 'echo it's fine', an unbalanced 3-quote sequence instead of 2. This corrupts the quote-delimited token stream urunit parses out of /proc/cmdline to reconstruct argv for the guest's init process.

What you expected to happen:
Arguments containing a single quote should be safely escaped when embedded in the boot cmdline (or rejected with a clear error), so the guest's init process always receives exactly the arguments the user specified.

How to reproduce:

  1. Build a Linux-unikernel-type urunc container (bima image using urunit as init) with an OCI spec process.args entry containing a space and a single quote, e.g. ["/urunit", "sh", "-c", "echo it's broken"].
  2. Run the container with urunc create/urunc run.
  3. Inspect the guest's /proc/cmdline (or the argv urunit actually launches): the init=... -- ... segment contains 'sh' 'echo it's broken', an unbalanced quote sequence, instead of the two intended tokens.
  4. Observe urunit either fails to parse the cmdline correctly or launches init with a different, wrong argument split than what was configured.

Impact:
Silent corruption of the command actually executed inside Linux-based unikernel guests whenever a workload's argument legitimately contains a single quote alongside whitespace (a common shell pattern, e.g. sh -c "it's ..."). Because the corrupted string is image-author-controlled and unescaped in a token-boundary-sensitive parser, the damage isn't confined to that one argument's text, it shifts where the parser believes subsequent arguments start and end, so containers can run the wrong command with no error surfaced to the user.

Suggested fix:
Escape embedded single quotes when wrapping an argument (shell-style ' to '\''), or reject arguments containing quote characters with a clear error until proper escaping is implemented.

Environment:

  • urunc version: main branch
  • Hypervisor backend: any hypervisor used with the linux unikernel type (QEMU, Firecracker, Cloud Hypervisor), the bug is in the shared guest driver, not hypervisor-specific code
  • OS: Linux

PROOF IT IS REAL:

  • Verified current code directly: pkg/unikontainers/unikernels/linux.go lines 248-272 (parseCmdLine) and 124-126 (CommandString) match exactly as quoted above, no escaping of quote characters exists anywhere in the file, only strings.TrimSpace.
  • This is distinct from the closed issue #666 ("QEMU Command Injection via OCI Annotation causing args.Command Split on Spaces"), which concerned pkg/unikontainers/hypervisors/qemu.go's BuildExecCmd splitting cmdString by spaces, confirmed that code now appends args.Command as a single unsplit argument to -append, so that issue is already fixed and unrelated to this one, which is about how args.Command's content gets built in the first place.
  • Not one of the 5 pre-existing local fix branches (tap fd leak, mountinfo unescape, pivot_root decision, block-volume rollback, exec-stub Argo hang), none touch pkg/unikontainers/unikernels/.
  • Duplicate searches against open/closed issues and open/merged PRs for parseCmdLine, normalizedArgs, wrap multi-word, quoting, single quote, escape argument, urunit returned no matching prior report (only unrelated urunit topics like rlimits, graceful shutdown, and #666 above).
Lenguaje dominante
Go
Estrellas
298
Forks
205
Merge medio
2 d 18 h
PR fusionados (30 d)
27

Preparar el entorno

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 urunc-dev/urunc

Todos los issues de urunc-dev/urunc

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.