Bug 2547135 (CVE-2026-106450)

Summary:	CVE-2026-106450 org.lz4/lz4-java: lz4-java: Denial of Service via excessive memory allocation from crafted compressed streams
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security DevOps Team <prodsec-dev>
Status:	NEW ---	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	ant, anujha, asoldano, asyoung, bbaranow, bmaxwell, bstansbe, ccranfor, cescoffi, cmah, dlofthou, ewittman, fmariani, fmongiar, gmalinko, gsmet, gtanzill, istudens, ivassile, iweiss, janstey, jbuscemi, jhollowa, jmartisk, jnethert, jpechane, jwon, kaycoth, manderse, mcarlett, mosmerov, msvehla, nipatil, nwallace, olubyans, ozzy, pantinor, pberan, pdelbell, pesilva, pjindal, pmackay, prichard, rguimara, rhel-process-autobot, rkubis, rstancel, rstepani, sbiarozk, sthirugn, tcunning, thjenkin, varjain, vdosoudi, watson-tool-maintainers, yfang
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:	A flaw was found in lz4-java. By supplying a specially crafted stream containing many small frame headers, a remote attacker can trigger disproportionate memory allocations during decompression. This excessive allocation consumes substantial memory and processing resources, potentially leading to a Denial of Service (DoS).	Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	2550297
Bug Blocks:

Description OSIDB Bzimport 2026-10-06 20:02:32 UTC

yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.4, net.jpountz.lz4.LZ4FrameInputStream readHeader() allocates two new 4 MiB block buffers whenever a maximum-block-size frame header is read, and the default concatenated-frame mode allows attacker-controlled streams containing many minimal empty frames to trigger roughly 8 MiB of allocation for every 11 input bytes. The stream produces no decompressed output while consuming CPU and garbage-collection time, so decompressed-size limits do not mitigate the issue; readSingleFrame mode is not affected. This issue is fixed in version 1.11.4.