[BUG] - CPU spikes with long password input (no length limit)

[dwmongoose]

Summary

cosmic-greeter enters a high-CPU state when the password field contains a large number of characters. There appears to be no input length limit, allowing unbounded resource consumption. In extreme cases (thousands of characters from a held key), the greeter becomes unresponsive and consumes hours of CPU time.

Environment

• OS: Pop!_OS 24.04 LTS
• Kernel: Linux 6.17.9-76061709-generic
• Hardware: SLIMBOOK EVO15-AI9-STP
• CPU: AMD Ryzen AI 9 365 w/ Radeon 880M
• Display: Single monitor, Wayland
• cosmic-greeter: 0.1.0 (git commit f139612)

Steps to Reproduce

1. Lock the screen (Super+Escape or idle timeout)
2. Paste a large string into the password field (or hold down a key)
3. Observe CPU usage climbing

For extreme reproduction (original incident):

1. Open a browser with video paused
2. Close laptop lid (key held down by keyboard cover)
3. Key repeat fills password field with thousands of characters
4. Greeter becomes unresponsive

Observed Behavior

Controlled Test (pasting ~500 characters)

Monitoring with ps -o %cpu,cputime:

Timestamp | CPU% | CPU_Time | Memory
----------|------|----------|--------
21:03:10  |  0.6 | 00:00:08 | 119.7MB  ← Baseline (empty password field)
21:04:00  |  0.7 | 00:00:09 | 120.2MB  ← Started pasting
21:04:30  |  0.9 | 00:00:13 | 120.9MB
21:05:00  |  1.3 | 00:00:18 | 121.5MB
21:05:30  |  1.6 | 00:00:24 | 121.9MB
21:06:00  |  2.2 | 00:00:32 | 122.0MB
21:06:30  |  2.5 | 00:00:38 | 122.4MB  ← Peak (~4x baseline CPU)

Result: 30 seconds of CPU time consumed in ~3 minutes. CPU% scales linearly with input length.

Original Incident (thousands of characters from held key)

Journal entry after manual termination:

cosmic-greeter.scope: Consumed 4h 7min 3.554s CPU time.

Process was terminated via SIGTERM (killall cosmic-greeter). No crash/segfault - the greeter was stuck in a CPU-bound loop processing the massive input.

Expected Behavior

1. Password field should have a reasonable maximum length (128-256 characters)
2. CPU usage should not scale unboundedly with input length
3. Greeter should remain responsive regardless of input size

Root Cause Hypothesis

The greeter appears to perform expensive operations that scale with password length:

• Rendering password mask characters (●●●●...) for every character
• Possibly re-hashing or validating on each keystroke
• No input length cap to bound the work

Security Consideration

This could be considered a local denial-of-service vector:

• Anyone with physical access can freeze the lock screen by holding a key
• Cat walking on keyboard could trigger this
• Laptop lid + keyboard cover (as in original incident)

Additional Context

The original incident also involved:

• Brave browser with paused Jellyfin video (VA-API hardware decode)
• Lid close triggering suspend

However, the controlled reproduction (just pasting characters, no video/suspend) confirms the password input handling is sufficient to cause elevated CPU usage.

Suggested Fix

1. Add max_length to password input field (e.g., 256 chars)
2. Debounce expensive operations if processing per-keystroke
3. Consider async/background hashing if that's occurring on input