[Bug 3926] New: SIGSEGV in sshd-session caused by Subsystem directive inside conditional Match block

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=3926

            Bug ID: 3926
           Summary: SIGSEGV in sshd-session caused by Subsystem directive
                    inside conditional Match block
           Product: Portable OpenSSH
           Version: 10.0p2
          Hardware: ARM64
                OS: FreeBSD
            Status: NEW
          Severity: major
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: andy+mindrot at codeedog.com

**This is **NOT** a general DOS, the sshd config file must have a
misconfiguration for the segfault to occur.**

A Subsystem directive inside a conditional Match block causes
sshd-session to be killed by signal 11 (SIGSEGV) when a connection
matches that block. The client receives a dropped connection.

sshd -t accepts the configuration without error, which is expected
behavior given that Subsystem was intentionally made valid inside Match
blocks as part of the implementation in OpenSSH 9.5 (see Bug 1975). The
crash appears to be a regression in that implementation.

Reproducer
--------------
Port 22

PermitRootLogin no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no
ChallengeResponseAuthentication no
UseDNS no

Match User aUser
    Subsystem sftp /usr/libexec/sftp-server
--------------

Steps to reproduce:

1. Place the above configuration in /etc/ssh/sshd_config
2. Run sshd -t -f /etc/ssh/sshd_config → exits 0, no output (expected —
config is syntactically valid)
3. Start sshd: service sshd start (or equivalent)
4. Connect as user aUser via SSH
5. Observe sshd-session killed by signal 11

See attached complete report.

NOTE!

I encountered this bug during an AI assisted coding session (not vibe
coding) using Anthropic's Claude. I do not know how the dev team feels
about AI. Even so, there's no denying a misconfigured sshd_config file
causes a segfault.

I worked with the AI to diagnose and isolate the likely source of the
segfault. The attached report was generated from that work. Any
mistakes within are ultimately mine. However, some credit should go to
Claude (or their dev team) if this results in an actual bug fix as I
wouldn't have had the time to dig in as deeply at the AI did to analyze
the code.

I am curious if we found the correct region and look forward to seeing
how this bug progresses.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.