pocketmine/raklib reliable-ordered queue size is unlimited, allowing a session to hog server memory

published 2023-11-15 2y ago modified 2024-11-28 last yr.

cvss: 5.3; version 3.1, GitHub
cisa kev: Not listed; not in CISA's catalog
epss: —; no score, EPSS covers CVEs only
public exploits: 0; none known

### Impact A client can send reliable-ordered packets 0, 2, 3, 4, 5 ... etc, and all the packets 2 and up will stay in the reliable-ordered queue until 1 arrives. A malicious client can exploit this to waste all available server memory by simply never sending the missing packet. Since the server doesn't make any effort to limit the size of the queue or detect this kind of abuse, this problem is easy to abuse.

### Patches This bug was fixed on the 0.14.x and 0.15.x release lines by 371190f5854372154d1b263cd2a10e658e92bebe.

### Workarounds No workaround is known.

Patch / fix

fixed in 1 links 1

packagist pocketmine/raklib 0.14.6, 0.15.1

github.com/pmmp/RakLib@371190f commit

Is GHSA-w98g-5fmx-wm4x in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.

Check with Fencer

CVSS scores

assigned by	version	score	vector
GitHub	3.1	5.3	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

Affected packages

ecosystem	package	affected	fixed in
packagist	pocketmine/raklib	>=0.14.0, <0.14.6 >=0.15.0, <0.15.1	0.14.6 0.15.1

Classification

Weakness

CWE-400 Uncontrolled Resource Consumption

References

Sources

GitHub Advisory GHSA-w98g-5fmx-wm4x

Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.