We are seeing a regression in LightDM on Debian Trixie.
Environment
- Debian 13 (Trixie)
- lightdm 1.32.0-6+b2
- lightdm-gtk-greeter 2.0.9-1
Setup
We have used this setup for a long time without problems on Bullseye:
xvnc.socket listens on TCP 5900xvnc@.service starts:
Xvnc -inetd -query localhost -once -geometry 1920x1200 -SecurityTypes=TLSNone- LightDM has XDMCP enabled
A remote connection to TCP 5900 causes systemd to start Xvnc, which then makes a local XDMCP request to localhost:177.
Actual result
On Trixie, LightDM crashes and systemd restarts it, which resets the active desktop session.
Journal shows:
g_object_unref: assertion 'G_IS_OBJECT (object)' failed
double free or corruption (fasttop)
Source ID 30 was not found when attempting to remove it
lightdm.service: Main process exited, code=killed, status=6/ABRT
LightDM log shows the crash happens after an unmanaged XDMCP session times out:
Got Query(authentication_names=[]) from 127.0.0.1:63690
Got Request(display_number=1 ...) from 127.0.0.1:63690
Send Accept(session_id=53140 ...) to 127.0.0.1:63690
Timing out unmanaged session 53140
Expected result
LightDM should not crash when an unmanaged XDMCP session times out. It should clean up the session and continue running.
Regression
This same Xvnc/XDMCP arrangement worked on Debian Bullseye with LightDM 1.26.0. The crash started after moving to Trixie / LightDM 1.32.0.
Suspected cause
This looks like a double-free in the XDMCP unmanaged-session timeout path in 1.32.0.
In 1.32.0, src/xdmcp-server.c uses SessionData with:
- g_autoptr(SessionData) data = user_data;
- g_hash_table_remove(priv->sessions, ...)
and the hash table destroy callback also frees SessionData (session_data_free), which appears consistent with:
- double free or corruption (fasttop)
- Source ID ... was not found when attempting to remove it
Bullseye's 1.26.0 used different session lifetime handling and did not crash in this scenario.
Trigger in our case
This is triggered via network scanning against TCP 5900. For example, Rapid7 touching the VNC port starts Xvnc -query localhost, which causes the local XDMCP session and eventually the LightDM crash. This is something our IT department is forcing on us so we cannot ask them to stop this scan :) And we like the session handover using systemd sockets.
We are seeing a regression in LightDM on Debian Trixie.
Environment
Setup
We have used this setup for a long time without problems on Bullseye:
xvnc.socketlistens on TCP 5900xvnc@.servicestarts:Xvnc -inetd -query localhost -once -geometry 1920x1200 -SecurityTypes=TLSNoneA remote connection to TCP 5900 causes systemd to start Xvnc, which then makes a local XDMCP request to
localhost:177.Actual result
On Trixie, LightDM crashes and systemd restarts it, which resets the active desktop session.
Journal shows:
LightDM log shows the crash happens after an unmanaged XDMCP session times out:
Expected result
LightDM should not crash when an unmanaged XDMCP session times out. It should clean up the session and continue running.
Regression
This same Xvnc/XDMCP arrangement worked on Debian Bullseye with LightDM 1.26.0. The crash started after moving to Trixie / LightDM 1.32.0.
Suspected cause
This looks like a double-free in the XDMCP unmanaged-session timeout path in 1.32.0.
In 1.32.0, src/xdmcp-server.c uses SessionData with:
and the hash table destroy callback also frees SessionData (session_data_free), which appears consistent with:
Bullseye's 1.26.0 used different session lifetime handling and did not crash in this scenario.
Trigger in our case
This is triggered via network scanning against TCP 5900. For example, Rapid7 touching the VNC port starts Xvnc -query localhost, which causes the local XDMCP session and eventually the LightDM crash. This is something our IT department is forcing on us so we cannot ask them to stop this scan :) And we like the session handover using systemd sockets.