Potential OS Command Injection in nemo-autorun-software (Low Severity - Not Exploitable)

[rgfegegeegege]

Distribution

22

Package version

nemo 6.4.5

Frequency

Always

Bug description

A static analysis tool flagged a potential OS Command Injection (CWE-78) in the file src/nemo-autorun-software.c of the Nemo file manager (linuxmint/nemo repository). The issue involves the use of execl() on a path indirectly influenced by command-line input (argv[1]).
After manual review, local testing, and verification against current code (as of January 2026), this is not an exploitable vulnerability. It is a false positive from static analysis, with low security impact due to strong mitigations in the code design.
No public CVE exists for this specific issue, and no related exploits or discussions were found in searches across CVE databases, GitHub issues, or security forums.

Affected Component

Repository: https://github.com/linuxmint/nemo
File: src/nemo-autorun-software.c
Function: autorun() (around lines related to execl())
Binary: nemo-autorun-software (helper for autorun on removable media)

Description
The binary is invoked with a path/URI as argv[1] (e.g., a mounted USB drive).
Flow:

Parse argv[1] → create GFile → find enclosing mount (via GIO/GVFS).
In the mount root, search for specific hardcoded executable files: .autorun, autorun, or autorun.sh.
If found and executable → chdir() to mount root → execl() directly on the file (no shell involved).

flags this as command injection because argv[1] (unsanitized CLI input) indirectly influences the executed path.
Why It Is NOT Exploitable

The executed path is strictly limited to one of three hardcoded filenames in the mount root.
An attacker cannot force execution of arbitrary files or inject commands (e.g., via ; rm -rf / or path traversal) because:
GIO/GVFS normalizes and validates the mount resolution.
Only the fixed names are checked and executed.

Direct execl() (not system/shell) → no shell metacharacter interpretation.
Requires:
Physical/local access to insert media or mount a volume.
Presence of a malicious executable with one of the exact hardcoded names.
Explicit user confirmation via GTK dialog.

Local testing confirms legitimate files execute after user click, but malformed argv[1] simply fails.

This is a legacy autorun feature (inherited from Nautilus/GNOME, similar to old Windows Autorun.inf), intentionally risky by design but heavily bounded here.
Severity

Low (Informational / Hardening Opportunity)
CVSS-like estimate: ~3.0 (Local attack vector, low complexity, requires user interaction, no privilege escalation beyond user level).
No remote exploitation.
No known in-the-wild abuse.

Recommended Patch / Hardening (Inspired by Similar Fixes)
While not required for security, similar issues in other projects (e.g., path construction in fossology, unlink/link in hldig, plugin execution in munin-c) were mitigated by:

Adding explicit input validation (e.g., reject paths with .., /, or special chars).
Using safer APIs (e.g., g_spawn_async with explicit argv array instead of raw execl).
Or deprecating risky features.

Steps to reproduce

.

Expected behavior

.

Additional information

No response