[Live-devel] UAF on failed re-SETUP with reuseFirstSource

[Qingyang Zhou]

Hi everyone:

I found a heap-use-after-free in the LIVE555 RTSP server when an
OnDemandServerMediaSubsession uses reuseFirstSource=True.

Tested version: LIVE555 2026.06.29

Summary:
Two clients can SETUP the same stream/track, sharing one StreamState. If both
then send a failed re-SETUP for the same track/session, the shared StreamState
reference count can become inconsistent. Later full server cleanup crashes with
a UAF.

Client request shape:
Each of two separate RTSP client connections first sends normal requests like:

  DESCRIBE rtsp://<server>/live RTSP/1.0
  CSeq: 1
  Accept: application/sdp

  SETUP rtsp://<server>/live/track1 RTSP/1.0
  CSeq: 2
  Transport: RTP/AVP;unicast;client_port=<rtp>-<rtcp>

  PLAY rtsp://<server>/live RTSP/1.0
  CSeq: 3
  Session: <session-id>
  Range: npt=0-

Then each client sends a second SETUP for the same track/session, but without
the Transport header:

  SETUP rtsp://<server>/live/track1 RTSP/1.0
  CSeq: 4
  Session: <session-id>

Both malformed re-SETUP requests return "461 Unsupported Transport". The client
connections remain open until the server performs full cleanup.

Root cause:
RTSPClientSession::handleCmd_SETUP_afterLookup2() deletes the old stream token
before fully validating the new SETUP request. If the new SETUP fails, the
shared StreamState reference count has already been decremented, while another
session may still hold a stale streamToken.

ASan stack:
  OnDemandServerMediaSubsession::deleteStream()
    liveMedia/OnDemandServerMediaSubsession.cpp:383
  RTSPClientSession::reclaimStreamStates()
    liveMedia/RTSPServer.cpp:1307
  GenericMediaServer::cleanup()

I have a working PoC/reproducer ready. Because this is a remotely triggerable
UAF and the live-devel list is public, I would prefer not to post the full PoC
publicly. I can share it privately with the maintainer if needed.

If you confirm this bug and decide to request a CVE for this issue,
I can provide any additional technical details or materials you need.

Best regards,
Zhou Qingyang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20260704/204f288c/attachment.htm>